Author: cogumel0Subject: ProcDump bug
Posted: 19 May 2017 at 11:58am
As described in this MSDN blog
https://blogs.msdn.microsoft.com/granth/2012/07/02/how-to-take-a-memory-dump-of-an-asp-net-application-pool-quickly/ , capturing a crash dump of an IIS ASP.NET process can, in some instances, cause IIS to restart the process before the capture is complete, due to the process being suspended during the capture.
Also according to that blog, the parameter -r should be used, which tells ProcDump to create a clone of the process to create the dump for (focusing on Win8.1 and higher, using PssCaptureSnapshot API).
After some tests, it seems like there might be a bug here. Some processes cannot be cloned using PssCaptureSnapshot (API returns Access Denied). When attempting to clone and subsequently dump a process that cannot be cloned, ProcDump appears to simply ignore the clone flag and still create a dump of the "main" process. There is no visible indication that no clone was made, it just silently carries on with the dump without ever telling the user that capturing a dump straight out of the "main" process.
The reason for the clone is exactly to prevent the "main" process being suspended for a long period of time. To simply continue with the dump when it can't create a clone without telling the user anything or offering a parameter to counter this functionality is a massive problem imho with very real consequences.
I know a brand new version of ProcDump was released just two days ago where improvements where made to scenarios where one might want to perform a dump to IIS ASP.NET processes, but afaik it still does nothing to address this situation and my understanding is that using a clone is always better with things like IIS ASP.NET.
My understanding is that the additions to the new version of ProcDump bring absolutely no advantages when using clones, that these additions are only useful when *not* using clones.
In short, I think it's a bug that a dump of the "main" process is created when the user specifies that he'd like to use clones, even when it fails to create one. At the very least this should be documented with an optional parameter to tell ProcDump *not* to continue in case the clone dumps. In a perfect world the user would be asked what to do after it attempts to create a clone and fails.
OliverWeaver wrote:
