Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Re: windbg digest: February 25, 2017

Osiris_PedrosoOsiris_Pedroso Member Posts: 24
I found out about this article just today and all symptoms seem to match
you description.
Hope it is helpful.
https://blogs.msdn.microsoft.com/jeremyk/2004/07/19/dont-believe-everything-the-debugger-is-telling-you-aka-rootkit/

Good luck,
Osiris


On Sat, Feb 25, 2017 at 11:01 PM Kernel Debugging Interest List digest <
[email protected]> wrote:

> WINDBG Digest for Saturday, February 25, 2017.
>
> 1. RE: Test Machine unable to save memory dump files
> 2. RE:Test Machine unable to save memory dump files
>
> ----------------------------------------------------------------------
>
> Subject: RE: Test Machine unable to save memory dump files
> From: [email protected]
> Date: Sat, 25 Feb 2017 10:38:09 -0500 (EST)
> X-Message-Number: 1
>
> We have also seen the same sort of thing on some of our Win2008 machines.
> On some machines it works fine, and on others it does not. If we move the
> hard drive around, the problem follows the drive, so it's not something
> broken with the hardware.
>
> We even worked with Microsoft Support on the problem and didn't really get
> anywhere.
>
> One key discovery is that the dump works fine for us. If you power off
> the machine at the time of the reboot following the bluescreen, you can
> load up the pagefile.sys into WinDbg and it sees the memory.dmp just fine.
>
> That means that the problem is not with creating the dump, but in copying
> it to memory.dmp. One of my co-workers managed to follow that process a
> bit further, and when it doesn't work, he saw that there was some sort of
> access error when it tried to open the pagefile.sys while the system was
> booting up.
>
> Here are his notes which may be of use:
>
> Experimentation with running ProcMon in boot logging mode revealed some
> useful information about what works and doesn't work. Taed's earlier
> analysis that the dump is written correctly to the pagefile but never moved
> to MEMORY.DMP on the reboot is confirmed. The crash drivers for Windows
> 2008 are different than 2003, but that doesn't really matter here. (This
> gentlemen has done some interesting research into how it works now:
> https://crashdmp.wordpress.com/)
> smss.exe (Windows Session Manager) is responsible for determining if a
> crash dump exists and to properly dispose of the crash dump when found.
> smss.exe scans the following registry entries:
> HKLM\System\CurrentControlSet\Control\Session Manager\Memory
> Management\PagingFiles
> HKLM\System\CurrentControlSet\Control\Session Manager\Memory
> Management\PagefileOnOsVolume (only used for BitLocker apps)
> HKLM\System\CurrentControlSet\Control\Session Manager\Memory
> Management\ExistingPageFiles
> HKLM\System\CurrentControlSet\Control\CrashControl\DedicatedDumpFile
> HKLM\System\CurrentControlSet\Control\CrashControl\AutoReboot
> smss.exe then attempts to open "ExistingPageFiles" to read the first 4K to
> determine if a crash dump lives there. In every failure case I have
> recorded, the CreateFile call fails with a SHARING VIOLATION error. Because
> it cannot read the pagefile, smss.exe skips the effort to save the crash
> dump. smss.exe attempts to open the pagefile with the following access
> mode: Generic Read/Write, Delete, Write DAC. What I cannot figure out is
> why a sharing violation occurs. No other process has an open handle to the
> pagefile back to the point when ProcMon started collecting data. The
> sharing violation error is the only one I ever see, and it always occurs at
> the same point when the system is coming up.
> Now, if new NTFS partitions are created on the system or secondary drive,
> and the pagefile is located somewhere other than the system volume, then
> smss.exe has no problem accessing the pagefile. I have managed through
> various manipulations of the paging file to get smss.exe to occasionally
> open the pagefile on the system drive, but the problem eventually comes
> back within one or two subsequent reboots.
> One thing of note is that a system partition which has been upgraded to
> Windows 2008 has a different owner and set of security attributes on the
> C:\ directory than a partition natively created on Windows 2008.
> Natively-created partitions have SYSTEM as the owner and a security
> attribute for the "Everyone" object that allows read access just on C:\.
> System partitions upgraded from Windows 2003 to Windows 2008 (and also
> created by the deployment disk?) have "TrustedInstaller" as the owner and
> no security attribute for "Everyone". I see no reason for a sharing
> violation due to this unless there is an odd conflict with the ACL between
> smss.exe and the pagefile that results in a sharing violation as opposed to
> an access denied error.
>
>
> ----------------------------------------------------------------------
>
> Subject: RE:Test Machine unable to save memory dump files
> From: Tim Chan
> Date: Sat, 25 Feb 2017 17:51:18 -0800
> X-Message-Number: 2
>
> Thanks twynnell, there is more information here than what ms support (and
> their pro support) is able to give me. I will be giving it a second go on
> Monday
>
> On Feb 25, 2017 7:39 AM, wrote:
>
> We have also seen the same sort of thing on some of our Win2008 machines.
> On some machines it works fine, and on others it does not. If we move the
> hard drive around, the problem follows the drive, so it's not something
> broken with the hardware.
>
> We even worked with Microsoft Support on the problem and didn't really get
> anywhere.
>
> One key discovery is that the dump works fine for us. If you power off the
> machine at the time of the reboot following the bluescreen, you can load up
> the pagefile.sys into WinDbg and it sees the memory.dmp just fine.
>
> That means that the problem is not with creating the dump, but in copying
> it to memory.dmp. One of my co-workers managed to follow that process a
> bit further, and when it doesn't work, he saw that there was some sort of
> access error when it tried to open the pagefile.sys while the system was
> booting up.
>
> Here are his notes which may be of use:
>
> Experimentation with running ProcMon in boot logging mode revealed some
> useful information about what works and doesn't work. Taed's earlier
> analysis that the dump is written correctly to the pagefile but never moved
> to MEMORY.DMP on the reboot is confirmed. The crash drivers for Windows
> 2008 are different than 2003, but that doesn't really matter here. (This
> gentlemen has done some interesting research into how it works now:
> https://crashdmp.wordpress.com/)
> smss.exe (Windows Session Manager) is responsible for determining if a
> crash dump exists and to properly dispose of the crash dump when found.
> smss.exe scans the following registry entries:
> HKLM\System\CurrentControlSet\Control\Session Manager\Memory
> Management\PagingFiles
> HKLM\System\CurrentControlSet\Control\Session Manager\Memory
> Management\PagefileOnOsVolume (only used for BitLocker apps)
> HKLM\System\CurrentControlSet\Control\Session Manager\Memory
> Management\ExistingPageFiles
> HKLM\System\CurrentControlSet\Control\CrashControl\DedicatedDumpFile
> HKLM\System\CurrentControlSet\Control\CrashControl\AutoReboot
> smss.exe then attempts to open "ExistingPageFiles" to read the first 4K to
> determine if a crash dump lives there. In every failure case I have
> recorded, the CreateFile call fails with a SHARING VIOLATION error. Because
> it cannot read the pagefile, smss.exe skips the effort to save the crash
> dump. smss.exe attempts to open the pagefile with the following access
> mode: Generic Read/Write, Delete, Write DAC. What I cannot figure out is
> why a sharing violation occurs. No other process has an open handle to the
> pagefile back to the point when ProcMon started collecting data. The
> sharing violation error is the only one I ever see, and it always occurs at
> the same point when the system is coming up.
> Now, if new NTFS partitions are created on the system or secondary drive,
> and the pagefile is located somewhere other than the system volume, then
> smss.exe has no problem accessing the pagefile. I have managed through
> various manipulations of the paging file to get smss.exe to occasionally
> open the pagefile on the system drive, but the problem eventually comes
> back within one or two subsequent reboots.
> One thing of note is that a system partition which has been upgraded to
> Windows 2008 has a different owner and set of security attributes on the
> C:\ directory than a partition natively created on Windows 2008.
> Natively-created partitions have SYSTEM as the owner and a security
> attribute for the "Everyone" object that allows read access just on C:\.
> System partitions upgraded from Windows 2003 to Windows 2008 (and also
> created by the deployment disk?) have "TrustedInstaller" as the owner and
> no security attribute for "Everyone". I see no reason for a sharing
> violation due to this unless there is an odd conflict with the ACL between
> smss.exe and the pagefile that results in a sharing violation as opposed to
> an access denied error.
>
>
> ---
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
>
> ---
>
> END OF DIGEST
>
> ---
> You are currently subscribed to windbg as: [email protected]
> To unsubscribe send a blank email to [email protected]
>
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA