Did you know? You can unwind the call stack from exceptions (Bill Horst)

VBTeam — Tue, 09 Dec 2008 19:00:00 GMT

The ability to unwind the call stack from exceptions is one of the debugger features that was newly introduced in Visual Basic.NET 2005. When the debugger hits a first-chance exception, you can unwind the call stack in order to make code edits to fix the exception and continue debugging with the changes. The exception assistant UI will have an “Enable Editing” option which will unwind the debugger to the topmost call stack frame with code in the current solution.

When an exception is unhandled, the unwind will occur automatically, but this can be turned on and off from the Options dialog (under Tools).

If you attempt to edit code after an exception has been hit, but before an unwind, you're allowed the option of unwinding and editing the code, stopping the debugging session, or canceling the edit.

The user can also unwind from the call stack window, by right-clicking the desired frame and selecting “Unwind To This Frame”. This is only available when an exception has been hit and not yet unwound, and only on frames sufficiently high on the call stack.

We hope that this functionality will allow you to be more effective in their debugging, and will help you better leverage the “Edit and Continue” capabilities in Visual Basic.

Source code of Visual Basic runtime has been released to public. (Vladimir)

VBTeam — Sat, 19 Jan 2008 19:01:00 GMT

One of the things we have been working on recently was publishing sources of VisualBasic runtime library. I am very excited to announce that the sources of VB runtime (Microsoft.VisualBasic.dll) are publicly available now! This is a part of a more general work on making .Net Framework sources available to public ( http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx ). The most important result of this is that developers can see and debug through VB runtime code.

There is a very detailed description on how to set up VS debugger so that it could use framework sources (that includes VB runtime too). http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx . The article also describes possible issues and workarounds. For most cases everything should work fine, but in case if you have problems, you can refer to this article.

Let’s see some examples how this functionality can be used.

Debugging without runtime sources (normal case) .

I have created a simple VB app with a latebound call and then I have started a debugging session and stopped inside the function. Normally VS tries not to bother user with details of such calls and in the call stack it simply says "[External Code]".

Disabling “Just My code”.

Next step is disabling “Just My code” in debug options so that you could see calls that are not part of your code.

After disabling “Just My code” in debug options, you will notice that were couple calls performed before we reached the target function. Indeed since compiler does not know at compile time what function will be called it delegates the call to the latebound call support in the runtime library. What we see on the stack in between our functions is the code in VB runtime library. At this point these stack frames are grayed out and pretty much useless as VS does not have sources that correspond to these frames. Double clicking causes this message:

Configre source location information

Now, since the sources of Microsoft.VisualBasic are now published we can tell VS where to get them. For that we will use source server support in VS.
(note that for this to work you will need to make sure you have installed the following QFE Visual Studio 2008 QFE as this hotfix updates a debugger component that fetches the source files).

1.            In Visual Studio 2008 and select Tools -> Options -> Debugging
2.            On the “General” Tab
             a.            Uncheck “Just My Code”
             b.            Check “Enable Enable Source Server Support”

Here we will tell VS where the sources are located and where to cache them locally. The caching is important when sources are accessed from a remote server as it is much faster to get sources from a local cache.

On the “Symbols” tab
a.            Click the “new” icon and enter: http://referencesource.microsoft.com/symbols
b.            Check “Search the above locations only when symbols are loaded manually”
c.             Enter a path in the textbox in which to cache symbols. Make sure this is somewhere that your user account has permissions to write to (for example d:\symbols)
d.            Hit OK

Right click the first runtime frame and select “LoadSymbols”. Wait for symbols to load (may take a moment or two and the first time it will also ask to agree with EULA). Doubleclick the first runtime frame… What a difference!!! We can see the runtime code.
(at thirst it may take some time as VS is fetching sources from a remote server, but once they are in the cache it will not do it again)

Setting breakponts inside VB runtime.

Even more - We can F11 through the runtime code and set breakpoints. If you are very curious, you can set a break point at the beginning of the latebound call helper and restart your project. Once you hit the breakpoint you can F11 through latebinder code to see how it was implemented.

Note that there is one caveat – while the sources on the server contain the same code as original sources they are not “exactly" the same. They have small changes such as copyright banners at the end etc. As a result VS complains about source difference.

This can be safely dismissed by right clicking the breakpoint, opening “Location” menu and selecting “Allow source file to be different from the original location”. Tere is a way to do this globally, but I would not recommend this since this would affect all you projects.

Also to make sure that symbols are loaded before execution gets to the breakpoint, you will need to disable “manual only” loading for symbols.

This will cause all the symbols to be loaded on demand and that includes many .NET FX libraries so this may take some time when you launch debugging session.

This will cause all the symbols to be loaded on demand and that includes many .NET FX libraries so this may take some time when you launch debugging session. After symbols are loaded you should be able to hit the breakpoint in the runtime.

What is inside MsgBox

Another interesting scenario that should work now is F11 into VB runtime functions. One that I use the most seems to be MsgBox so let’s take a look what is inside.
In a hello world project we can set breakpoint on the call to MsgBox.

When breakpoint is hit just do F11. Wow!! Now we are inside MsgBox and can step through it to see how it works.

Known issues, FAQ

1) Accessing remote symbols is not very fast. This causes delays in VS when sources are fetched. Even with caching enabled in some scenarios VS checks whether information is current. You may get around this by going to Tools -> Options -> Debugging -> Symbols configuration and unchecking “Search the above locations when symbols are loaded manually” checkbox and then debug you project. It may take some time to load all sources (including various .Net libraries) in this configuration (often more than 50Mb will be loaded). After VS finished loading, go back to Tools -> Options -> Debugging -> Symbols and check the “Search the above locations…” checkbox and hit OK. This will prevent the debugger from connecting to the server when you do not want it.

2) Sometimes you may notice that some variables or methods are not available. The reason for this is that you are using Retail/Optimized version. One result of the retail optimizations is that certain information is not available or “inlined”. You will still have the source information, but you may not be able to access the data or set breakpoints. For the most part however everything should be normal.

3) Will this work with VB Express?
No. This functionality relies on some VisualStudio components that Express versions do not have.

- Vladimir, VisualBasic team

Customizing Displays in the Debugger for System Types

VBTeam — Sat, 29 Sep 2007 02:04:07 GMT

We've heard feedback from several customers regarding the way certain types are displayed in the Debugger. Many of the displays exist to maintain the user experience between versions of Visual Studio. We constantly evaluate if this is the correct choice for a given version of the product.

Starting with VS2008, you don't have to wait for us any longer. In VS2008, VB added full support for many of the debugging features it lacked compared to C# in 2005. In particular we've added full support for the DebuggerDisplayAttribute.

By attributing a class or member with this attribute you can control how it is displayed in the debugger. For each column (name, value and type) you can provide an alternate string or expression to display.

The best part about this attribute is you can target types that exist in different libraries. You don't even need the source for them. One of the members in the Type field which species the target type. Customizing a type in a separate library requires slightly more work than customizing a type you have the source for. For a source project you can just apply the attribute directly to the type or member and it will display. For a type in another library you need to do the following.

Define a class library and include all of the DebuggerDisplayAttribute you want. Make sure to apply the attributes to the assembly and specify the Type member. Ex.

<Assembly: DebuggerDisplay("{ToString}", Target:=GetType(Guid))>

Place the built library under the folder "Visual Studio 2008\Visualizers" which is under your my documents folder.

After doing this any Guid type will now show up as the actual Guid String ("10f3c4eb-7c0f-41b1-ae83-8838ff2f4f70") instead of {System.Guid}

Jared http://blogs.msdn.com/jaredpar/

The Visual Basic Team : Debugger

Did you know? You can unwind the call stack from exceptions (Bill Horst)

Source code of Visual Basic runtime has been released to public. (Vladimir)

Customizing Displays in the Debugger for System Types