Windows Explored

I like to play with post mortem debuggers to help troubleshoot issues with crashing or hanging application by doing some basic analysis of the dump files. Often times I change the Windows debugger between Dr Watson and WinDbg on my Windows Xp workstations. To make Windbg the default debugger you can go into the command shell and run the following command: Windbg –I. After doing this many times previously, I was surprised when I encountered the following error when trying to change the debugger on my Windows 7 workstation. “WinDbg was not successfully installed as the default postmortem debugger. This operaton requires administrative privileges.”

But I was already running from an elevated command prompt. This was odd because a few weeks earlier I had no trouble doing this. Trying the same thing on the Windows XP workstation: “Cannot edit Debugger: Error writing the value’s new contents.”

Alternatively, you can also manually set any debugger as the default by creating the proper strings and values in HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug. But when I tried editing the registry directly by creating a string named Debugger I ran into another error: “Error Renaming Value. The Registry Editor cannot rename New Value #1. Error while renaming value.”

To investigate, I turned to Process Monitor and ran windbg –I from the command shell again, stopping the trace once the Windbg error was encountered. The trace was not filtered since I was not certain which other processes besides regedit were involved, but I knew I was dealing with an Access Denied result somewhere. You can quickly sort occurrences in the trace by going to Tools > Count Occurrences. Filtering for Results there was a single Access Denied on the AeDebug key:


Sometimes, you can look to the stack of the operation to get some clues of modules might be involved, focusing on 3rd party stuff. In this case, though, nothing stood out, these are all Windows out-of-the-box components:

Another approach is to look at operations before or after the operation(s) being focused on. To do that, I only needed to remove the Access Denied filter (the access denied filter will remain in focus). An important clue reveals itself:

A component of our AV security suite is writing to one of its log files. I right-clicked the operation and selected Jump To, which opens the log file in Notepad. Scrolling to the bottom of the file reveals that this registry operation is being blocked:

We can also see the operation is being blocked by going directly into the AV Protection Console:

I am sure there is a valid reason for this but I can’t find any documentation on why. I don’t know how the exception works on the backend of our AV security suite but it seems it can be worked around by modifying the rule controlling this behavior. It is a bit elaborate though in its current form: I had to create a batch file that would then call a reg file that contains the new values. This needs to be done for each debugger you would like to set as the default.