31–40 of 41 posts
For versions of Windows before 10, I'd agree with this 100%. Windows 10 (or maybe 8-8.1?) pulled in a lot of functionality from Process Explorer and is much improved. For developers Process Explorer (and ProcMon and a few other utils) is likely an improvement, but frankly if you're doing Windows development you should already have learned about them and probably some of Nir Sofer's tools as well (nirsoft.net). For 90…
This article correctly states that committed memory is that in use + memory that's being paged out. Now why would you want to know the committed memory over the actual physical RAM in use? I can trivially create an app that memory maps a massive file and will show several GB of committed memory. This won't be in use of course, memory mapping files so that the OS will page in/out as required is intentional. Those GB o…
OOOOOOO, something I actually know! > Now why would you want to know the committed memory over the actual physical RAM in use? Because in Windows, committed size is relative to physical size. You can commit a lot more than RAM, but watch your page-file grow. malloc() can fail on Windows for this reason. This is not the same on Linux or any of the BSD's I've tried. :) I experienced/discovered this August last year.. s…
Earlier quoted context omitted.
I'm not going to dispute that but just want to highlight it doesn't change the fact that committed RAM can show as extremely high just by working with memory mapped files. Memory mapping a GB log file for example will absolutely show GB's of committed memory but in reality you'll only have the last page in actual physical RAM.
Right. When you memory-map a file, what you've essentially done is add a temporary new pagefile to the system (your mapped file), and when you work with memory backed by that file, it's no different from working with "anonymous" memory backed by the system-wide pagefile.
Thank you.
We took the site down. Archive.org has a copy/mirror: https://web.archive.org/web/20190106190255/https://mahdytech...
This is the most occurring case where I look into memory. This will probably be the case for most windows users who know about the Task Manager out there and there is no reason for them to "not use Task Manager" anymore.
I hate those generalizing click bait headlines...they should at least come up with some equal justification for that.
Does anyone understand the story behind Process Explorer? For 10 years it's been an invaluable tool. But despite being developed by Microsoft you have to install it like third party software. Doesn't even come with an installer! How come it never got integrated into the main OS?
Depending on whom you ask that is actually a good thing. There's already enough software which is completely portable by nature, i.e. just a directory or even single executable which you can put anywhere, but still gets shipped as an installer only. Which depending on who wrote it might or might not get rid of artefacts again.
Apart from that: just like many, many other software it's easy to acquire via PowerShell's package management in which case it will even be in your PATH. If you've got everything setup it's Install-Package sysinternals. You might need Install-PackageProvider ChocolateyGet and Import-PackageProvider ChocolateyGet before that.
How come it never got integrated into the main OS?
I think the story goes something like 'Mark Russinovich created sysinternals, it was awesome enough for MS to embrace it, but deemed too technical and too much for power-users to be part of Windows'. A logic which is understandable in a way. Also if you opt for procexp to replace Task Manager it actually is integrated in the OS.
Does anyone understand the story behind Process Explorer? For 10 years it's been an invaluable tool. But despite being developed by Microsoft you have to install it like third party software. Doesn't even come with an installer! How come it never got integrated into the main OS?
Not having an installer is actually a bonus. Far too many "simple" Windows programs seem to need Gigabytes of DLLs installing to Windows folder and spray themselves all over the system. /Windows bloats massively after a couple of years of active use. An exe I can keep in a folder, or drop into the path and simply delete if no longer useful.
Does anyone understand the story behind Process Explorer? For 10 years it's been an invaluable tool. But despite being developed by Microsoft you have to install it like third party software. Doesn't even come with an installer! How come it never got integrated into the main OS?
It originally started out as something from NTInternals. They were building small utils with capabilities similar to what they had become used to in their Unix background. Then they focused on all the low level tools which led to MS buying them. Not having an installer is actually a bonus. Far too many "simple" Windows programs seem to need Gigabytes of DLLs installing to Windows folder and spray themselves all over…
Earlier quoted context omitted.
OOOOOOO, something I actually know! > Now why would you want to know the committed memory over the actual physical RAM in use? Because in Windows, committed size is relative to physical size. You can commit a lot more than RAM, but watch your page-file grow. malloc() can fail on Windows for this reason. This is not the same on Linux or any of the BSD's I've tried. :) I experienced/discovered this August last year.. s…
> This is not the same on Linux Linux lets you choose an overcommit policy. https://www.kernel.org/doc/Documentation/vm/overcommit-accou...
This is a real pain when moving an application from FreeBSD to Linux, as effective limits on memory are lost (ulimit set at ~90% of ram results in a malloc failure and a clean crashdump rather than death by thrashing, or an untrapable oom kill).
There could maybe be a middle ground where malloc would allocate large chunks of address space for ease of administration, and then ask the OS to commit those pages in smaller chunks as needed. Often, there's not much a lot you can do when allocation fails, but it's way more actionable if the failure is returned from a syscall vs failing when you write to an unbacked page, which could happen basically anywhere in your program.