共用方式為

Bugchecking a Computer on A Usermode Application Crash

  • 發行項

Hello my name is Gurpreet Singh Jutla and I would like to share information on how we can bugcheck a box on any usermode application crash. Set the application as a critical process when the application crash is reproducible. We may sometimes need a complete memory dump to investigate the information from kernel mode on a usermode application crash or closure.

 

We will use the operating system’s ability to mark a process as critical and cause the system to bugcheck when the critical process closes unexpectedly. This will generate either a CRITICAL_PROCESS_DIED or a CRITICAL_OBJECT_TERMINATION bugcheck.

 

For this demonstration I will use the following code sample which waits for the user input and then causes an Access Violation. You can use the following steps to collect a complete memory dump for any application crash that launches fine but crashes under known repro conditions.

 

Code Sample

#include<conio.h>
void main()
{
      _getch();      //Wait for a key press
      *(char*)0xdeaddead ='B';      //Causes the Access Violation
}

 

Please follow the steps below

  1. Set the system for a complete memory dump by opening the “Advanced System settings” under System properties in control panel and then setting the value of “Write debugging information” under “Startup and recovery” options on the advanced tab.
         
    image001

    image002
         

  2. Also enable the debug mode by running the following command from a command prompt
    bcdedit -debug on

  3. To enable the “Complete memory dump” and debug mode you need to restart the box to ensure the changes are implemented.

  4. Run the application you want to setup as critical process but do not run the repro steps. I have compiled my test application as test.exe

  5. Download and install the Debugging Tools for Windows, part of SDK which you can download from https://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx. Note, when the installer launches you can uncheck every feature except Debugging Tools for Windows.

  6. We need to setup the debugger to use the public symbols. Create a folder c:\symbols. Run Windbg with admin privileges, choose “File” menu and then “Symbol file path”. Type SRV*c:\symbols*https://msdl.microsoft.com/download/symbols
    For more details check https://support.microsoft.com/kb/311503/en-us

  7. Assuming you have the debugger installed and setup with the public symbols, launch the debugger with admin privileges.

  8. From the file menu select kernel debug and then choose the “Local” tab and hit Ok button. This will connect the windbg to the local kernel. You should see an “lkd>” prompt.

  9. Run the following command to get the process information in windbg. The below example uses both x64 and x86 architectures

     

    x64
    0: kd> !process 0 0 test.exe

    PROCESS fffffa82fa924b30

        SessionId: 0  Cid: 036c    Peb: 7fffffda000  ParentCid: 02e4

       DirBase: 1085d76000  ObjectTable: fffff8a0042d7970  HandleCount: 11.

        Image: test.exe

    x86
    0: kd> !process 0 0 test.exe

    PROCESS 89038a08  SessionId: 0  Cid: 10f0    Peb: 7ffde000  ParentCid: 0f10

        DirBase: bfa19900  ObjectTable: e669b630  HandleCount: 11.

        Image: test.exe

     

  10. Take the process id from the output and run the following command. The following command shows the process flags. The output shows the flags as 144d0841 in the example for x64 and 0x44082d for x86.

     

    x64
    0: kd> dt nt!_eprocess fffffa82fa924b30 flags

       +0x440 Flags : 0x144d0801

    x86
    0: kd> dt 89038a08 nt!_eprocess flags

       +0x240 Flags : 0x450801

     

  11. Run the ed command to edit the memory and set the process flags to mark the process critical. Adding the value 0x2000 marks the process critical.

     

    x64
    0: kd> ed fffffa82fa924b30+0x440 0x144d0801+0x2000

    x86
    0: kd> ed 89038a08+0x228 0x450801+0x2000

     

  12. Now close the debugger and proceed with the repro steps to crash or close the application.

  13. In our case the test application with the code mentioned above should cause the machine to bugcheck as soon as any key is pressed.

 

The complete memory dump will contain the process information as well as kernel data for investigation.

Comments

  • Anonymous
    June 23, 2014
    You set the process as critical, and then you terminate it.  What did you expect would happen?  It's a critical process, meaning that the system is dependent on its running.  If you take that away, then of course the system is going to crash. [We expected it to crash.  This is a technique to be used on purpose, to capture a kernel dump when a user mode application exits.  Sometimes there is value in examining kernel data or examining the state of multiple processes.]

  • Anonymous
    June 24, 2014
    Can I do this outside of debugger using process explorer or procmon.. [The undocumented API NtSetInformationProcess can be used to set a process as critical, accomplishing the same thing as what we did in the debugger.  I don't know of any tools that include this functionality, and as an undocumented API I don't encourage the creation of such a tool (undocumented APIs may change without notice).  Check our twitter feed (@ntdebugging), a reader recently tweeted an example of doing this in powershell.]