• Ntdebugging Blog

    Bugchecking a Computer on A Usermode Application Crash

    • 2 Comments

    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 http://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*http://msdl.microsoft.com/download/symbols
      For more details check http://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
    10.  

      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

       

    11. 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.
    12.  

      x64
      0: kd> dt nt!_eprocess fffffa82fa924b30 flags

         +0x440 Flags : 0x144d0801

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

         +0x240 Flags : 0x450801

       

    13. 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.
    14.  

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


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

       

    15. Now close the debugger and proceed with the repro steps to crash or close the application.
    16. 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.

Page 1 of 1 (1 items)