[SOLVED] Access is Denied with Kernel Memory Dump [WinDbg]

[x BlueRobot]

Okay, so I've been using the Sysinternals NotMyFault program to generate some Kernel Memory dumps, to demonstrate some extensions and commands. The dump files yesterday, weren't causing problems at all, apart from when the dump file was still within the C:\Windows folder. I moved the dump file to my Desktop, and that solved yesterday's access denied problems.

Today, I tried the same procedure and even ran Windows Explorer as a Administrator, both these methods didn't work. As a result, I decided to use ProcMon to get a trace on what was happening, I haven't really used ProcMon much so if want to run it again to gather more information, then please say so.





Here's the stack trace, the CreateFileW is the point in which Windows attempts to open the dump file and then return a handle to the WinDbg process object.



Here's my security permissions for the file:

 

[x BlueRobot]

I've managed to find a solution, simply click and open Start, type WinDbg and then right-click the program name. Select the Run As Administrator option, and then open the dump file from within the program itself.

 

[usasma]

I'm not real good w/ProcMon logs, but it seems that MEMORY.dmp is trying to be created (written) and all that's granted is Read access - so an Access Denied error is thrown.

I'd expect that "Run as administrator" would overcome this if it's able (as you've demonstrated).

I'm curious if there were any errors reported in EventViewer at this time.

 

[x BlueRobot]

I'll see if I can find anything in the Event Viewer for you.

Update:

I couldn't see anything related to the problem.

 

[jcgriff2]

...The dump files yesterday, weren't causing problems at all, apart from when the dump file was still within the C:\Windows folder. I moved the dump file to my Desktop, and that solved yesterday's access denied problems.

Today, I tried the same procedure and even ran Windows Explorer as a Administrator, both these methods didn't work. As a result, I decided to use ProcMon to get a trace on what was happening, I haven't really used ProcMon much so if want to run it again to gather more information, then please say so.

I've managed to find a solution, simply click and open Start, type WinDbg and then right-click the program name. Select the Run As Administrator option, and then open the dump file from within the program itself.

Be sure to set up Windbg as the default handler for dump files & set Windbg to "Run as Admin" via "Compatibility" tab in Windows Explorer -

https://www.sysnative.com/forums/bs...dump-files-windbg-symbol-setup.html#post58642

We usually deal with kernel dumps in %userprofile%\SysnativeBSODApps, which is created by writhziden's BSOD kernel dump automation processing app -

https://www.sysnative.com/forums/bs...een-of-death-processing-apps-2.html#post46231

All dump processing is automated and directly interfaces with John Carrona's (usasma) Driver Reference Table (DRT) , which ID's 3rd party drivers.

Carrona DRT - http://www.carrona.org/dvrref.php
Sysnative Mirror - http://www.sysnative.com/drivers/

You should check Mike's app out if you have not already done so. There are also DLLs written by niemiro & much more.

Obviously, there are times when you need to run Windbg GUI itself. For example, I do so for 0x9f (0x3,,,) & use the !irp command, if necessary.

Kind Regards. . .

John

 

[x BlueRobot]

I do have WinDbg as the default program for .dmp files, and have just changed the Compatibility setting for WinDbg too.