Blog Post: Drwtsn32 on Windows Vista/Windows Server 2008/Windows 7/Windows Server 2008 R2

 

Applies to:

Windows Vista

Windows Server 2008

Windows 7

Windows Server 2008 R2

I have been noticing a lot of IT Administrators and my fellow colleagues not fully utilizing the built-in post-mortem debugger.

In Windows XP and Windows Server 2003, when an application or service crashed, you would either get a Dr. Watson log (drwtsn32.log and user.dmp) or Windows Error Reporting (WER) log.
308538 Description of the Dr. Watson for Windows (Drwtsn32.exe) Tool
http://support.microsoft.com/?id=308538

310414 How To Configure and Use Error Reporting in Windows XP
http://support.microsoft.com/?id=310414

 

Since there is no Drwtsn32.exe on Vista/Server 2008/Windows 7/Server 2008 R2, we get to use the W.E.R.

You still receive the same "Event ID 1000" application error in the Application event log as you did with the legacy OS'es.

When an application or service crashes (a.k.a. access violation), there are multiple locations that you should check for a user mode dump (user.dmp)

If the crashing application is User Access Control (UAC) elevated, the dumps will be located at

C:\ProgramData\Microsoft\Windows\WER\ReportArchive
or
C:\ProgramData\Microsoft\Windows\WER\ReportQueue depending on whether queue mode is set or not.

If the application is not UAC elevated (LUA), it will be at

C:\Users\UserProfileName\AppData\Local\Microsoft\Windows\WER\ReportArchive
Note:  Where UserProfileName is the actual user profile name.
or
C:\Users\UserProfileName\AppData\Local\Microsoft\Windows\WER\ReportQueue

The easiest method to look for the user mode memory dumps is to go down to CMD (run as admin) or Powershell
Cd\ProgramData\Microsoft\Windows\WER\
dir *.*dmp /s

and

C:\Users\
dir *.*dmp /s

Note:  In Windows 7/Server 2008 R2, there has been an improvement on how dumps are collected. If the same application is crashing repeated, Windows 7/Server 2008 R2 optimizes so that it does not collect the dumps for the same type of crash more than once. This behavior is different from Windows Vista /Server 2008 where this was not the case. See http://msdn.microsoft.com/en-us/library/bb513628(VS.85).aspx and check out WER_SUBMIT_BYPASS_DATA_THROTTLING flag which changed the behavior in Windows 7/Server 2008 R2.

What if there are no .hdmp or .mdmp files?
You will want to tweak WER to collect the dmp files.

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\
Disabled (dword) 0 (hex)
LoggingDisabled (dword) 0 (hex)
ForceQueue (dword) 1 (hex)
DisableQueue (dword) 0 (hex)
MaxQueueCount (dword) 32 (he x)
    Note:  32 hex = 50 dec which is the default.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting
LocalDumps (Key)
DumpFolder (Expandable String Value) %LocalAppData%\CrashDumps
    Note:  System services is %WINDIR%\System32\Config\SystemProfile.
    For Network and Local Services, the folder is %WINDIR%\ServiceProfiles.

DumpType (DumpCount) 2 (hex)
    Note:  Where 2 is setting for a "Full Dump".
 
    For the details:
    Collecting User-Mode Dumps
    http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx

Alternativerly you have all these other post mortem debugger:
Adplus
ProcDump
DebugDiag

More information:
http://blogs.technet.com/b/arykhus/archive/2008/12/11/finding-useful-crash-data-and-windows-error-reporting-wer.aspx

http://blogs.msdn.com/b/wer/

http://msdn.microsoft.com/en-us/library/bb513628(VS.85).aspx

Windows Error Reporting and the Problem Reports and Solutions Feature in Windows Vista
http://technet.microsoft.com/en-us/library/cc709644(WS.10).aspx

Collecting User-Mode Dumps
http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx

Deanna Russo Cheryl Burke Olivia Wilde Paulina Rubio Kirsten Dunst