Sysinternals Homepage
Forum Home Forum Home > Sysinternals Utilities > Miscellaneous Utilities
  New Posts New Posts RSS Feed - ProcDump bug
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

ProcDump bug

 Post Reply Post Reply
Author
Message
cogumel0 View Drop Down
Newbie
Newbie


Joined: 19 May 2017
Status: Offline
Points: 3
Post Options Post Options   Thanks (0) Thanks(0)   Quote cogumel0 Quote  Post ReplyReply Direct Link To This Post Topic: 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.
Back to Top
cogumel0 View Drop Down
Newbie
Newbie


Joined: 19 May 2017
Status: Offline
Points: 3
Post Options Post Options   Thanks (0) Thanks(0)   Quote cogumel0 Quote  Post ReplyReply Direct Link To This Post Posted: 19 May 2017 at 12:05pm
Umm... ok... I *thought* I had tested the latest version and that it was still reacting the same, turns out I was running the old version.

On the new version, it properly throws an error: 

[14:02:55] Dump 1 error: Error writing dump file: 0x80070006
The handle is invalid. (0x80070006, -2147024890)

That being said, the actual error is Access Denied on the PssCreateSnapshot call, so it feels like it's reporting the wrong error and that this message could be made more user friendly.
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 11.06
Copyright ©2001-2016 Web Wiz Ltd.