Visual Studio Debugger IDE Issues

The Visual Studio 2002 IDE, and to a lesser extent the Visual Studio 2003 IDE, seems to have a few anomalies, probably related to its relative youth. This section discusses three of the most common IDE issues.

Window Behavior

In Visual Studio 2002, it's fairly common for a debugging window such as Locals or Autos to refuse to appear when you click its tab after docking the window to part of the IDE. This often seems to occur with the Properties window as well. The cause of this problem appears to be a battle for space between the Source window that usually occupies the center of the IDE and the surrounding debugging windows . This problem appears to be completely fixed in Visual Studio 2003, but if you're still using the older version, the quickest fix I've found is to hold down the Ctrl button while clicking the debugging window that you want to display.

Another rather more laborious way of fixing this problem is to unpin all of the other windows docked on that side of the IDE. Then hover the mouse pointer over the offending window and slowly move the pointer toward the edge of the Source window. As you cross the edge of the Source window, you should see the mouse pointer turn into a double-headed arrow, at which point you can drag the edge of the offending window toward the center of the screen, whereupon it will magically appear.

Yet another fix is to find and delete a file called devenv.xml. This file controls many of the IDE settings, including the positioning of the IDE windows. After you delete this XML file and restart Visual Studio, the file is rebuilt automatically and the data corruption within it that caused the window sticking disappears. Suddenly all of your debugging windows will come to life again.

The final fix that I've found for this problem is simply to reboot Visual Studio, although this can be annoying if you have to do it too often because startup speed can be quite slow. If you want Visual Studio to start as fast as possible, there's a trick to this too. First dock the Properties window and autohide it. Then, if you use the Dynamic Help window, dock that too and autohide it. Next, close Server Explorer and the Toolbox window. Finally, on the Start page set the switch marked "Show empty environment". Now when you reboot Visual Studio, you should find that it starts almost instantaneously, because it doesn't have to load the CLR during startup. From a clean desktop, you can press Ctrl-Esc, press R, type devenv , and press the Enter key ”from zero to Visual Studio loaded in 2 seconds or less.

Interpreting Chr(0)

Debugging windows, such as the Immediate and Watch windows, can become confused about how they represent the values of certain variables . The windows sometimes seem to be marooned somewhere between the native and managed views of the world, and this occurs in both Visual Studio 2002 and Visual Studio 2003.

For example, VB.Classic developers have long had to be careful about how they handle strings containing Chr(0), such as those returned by many Win32 API calls. Chr(0) is the character that C, and therefore Windows by default, uses to terminate strings. So what happens if you create a couple of these strings and then look at them in the Immediate window?

 Dim strTest1 As String = "123" & Chr(0) & "456789" Dim strTest2 As String = Chr(0) 

If you run some tests on these two strings, you can see the following results:

 ? strTest1.Length 10 ? strTest1="123" True ? strTest1 "123 ? strTest2.Length 1 ? strTest2="" True ? strTest2=Chr(0) True 

 

The first test result, showing the string's length, looks reasonable. The second test result looks rather strange . The third test result isn't a misprint ”printing of the string really does stop as soon as it hits the null terminator, and even the closing quotes are ignored. In a similar fashion, the fifth test contradicts both the fourth and sixth tests.

Debugger Single-Stepping

The Visual Studio 2002 debugger has a nasty habit of sometimes stepping onto a line of code that isn't actually being executed. Although this is irritating , it's thankfully the debugger that's showing you the wrong information and not a problem with the code itself. Often, rebuilding the project or the entire solution fixes the problem. At other times, even this doesn't work and you just have to ignore the debugger's eccentric behavior. This is a known bug caused by the debug symbols information in the .pdb file being emitted incorrectly, and it appears to have been fixed in Visual Studio 2003.