The problem is that the debugger is trying to determine what version of the .NET Framework your class library will load into, and the debugger has guessed incorrectly.

The work around for this is to add a config file next to the native executable to tell the debugger what version of the .NET Framework to debug.

So if you are trying to debug c:\proj\MyNativeProject\debug\MyNativeProject.exe, then create c:\proj\MyNativeProject\debug\MyNativeProject.exe.config with this content:

<?xml version ="1.0"?>
<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727" />
    </startup>
</configuration>

First, Rico wrote up the basic approach back in 2004, so you should start by reading this - https://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx. This will give you an intro to using sos.dll in WinDbg.

What I would like to add:

#1: How to decide if you have a leak in the first place.

Since GC's happen non-deterministically, it can be hard to know if you actually have a managed leak. For example, if you look at memory usage at the end of a user scenario, you will likely see memory usage all over the map based on when the last GC happened. The best technique I found for this is to stop after gen-2 collections. This isn't perfect since gen-2 collections can still happen at any time in your code, but it still gives you a better estimate then stopping after user scenarios.

To stop after the next gen-2 GC: !findroots -gen 2

Note that this command is new for the CLRv4 version of sos.dll (also available in Silverlight). I am assuming that you could achieve similar functionality with a well-placed breakpoint in older CLRs, but I am not familiar enough with the inner workings of the GC to tell you where.

#2: Use CLRProfiler to visualize the leaks

This may have been specific to my scenario, but I didn't have a lot of success with !gcroot. I had more success understanding the problem by loading up a .log file in CLRProfiler (https://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-8926-862b40aa0cd0&DisplayLang=en). One note that I found here was to _not_ use '-xml' when saving out the log as CLRProfiler doesn't understand the XML format.

To save the log out: !TraverseHeap c:\users\greggm\desktop\myheap.log

#3: !gcroot doesn't show roots in CCW's

When native code calls into managed code from COM, native code gets a CCW (COM callable wrapper). If native code leak's its CCW, the managed object will be leaked, but !gcroot will not tell you why.

Example:
    [ComVisible(true)]

    sealed class MyObject : IMyInterface, ICustomQueryInterface

    {

        CustomQueryInterfaceResult ICustomQueryInterface.GetInterface(ref Guid iid, out IntPtr ppv)

        {

            Debugger.Log(1, "MyObject", "MyObject: QI'ed for " + iid.ToString() + "\n");

            ppv = IntPtr.Zero;

            return CustomQueryInterfaceResult.NotHandled;

        }

    };

This left me with one problem - what to do with my old test machine which was too old to support Hyper-V, but too new to just throw away. Fortunately, Win7 came to my rescue by adding support for booting off a VHD (virtual hard disk). Now I can use differencing virtual hard disks, as a poor-man's Hyper-V and still get some millage out of my old test boxes.

Basic reimaging procedure:

1. Boot to my physical hard drive
2. Delete the current differencing disk
3. Create a new differencing disk
4. Boot back to my differencing disk
5. Rejoin the domain and install my test software (Visual Studio in my case)

Here is how I set this up:

1. Installed Win7 to my physical hard drive
2. After that install completed, I created a new Virtual Hard disk from the Disk Management MMC tool (Computer Management->Storage->Disk Management). I created a fixed Virtual Hard drive but I actually think that I dynamic disk would have been better since most of the parent virtual hard disk will remain empty. I named this file c:\windows7.vhd.
3. Boot to the Win7 installer again to install a second partition of Win7 on the VHD
4. After the installer finishes initializing, go to the repair tools and open a command prompt
• Run 'diskpart'
• select vdisk file=c:\windows7.vhd.
• attach vdisk
• exit
5. Now continue the Win7 installer, select the virtual disk as the partition to install to. Note that in RC builds, Win7 will warn you that Windows cannot install to this partition, but this warning appears to be ignorable.
6. After the install completes, install anything else to that parent partition that you need (ex: development tools, baseline libraries, etc).
7. Boot back to the physical hard drive.
8. Create a new differing vhd using the 'diskpart' tool (create vdisk file=c:\windows7.diff.vhd parent=c:\windows7.vhd)
9. Add a new boot menu entry for the differencing vhd, and set it as the default:
• bcdedit /copy {guid_of_vdisk} /d "Win7 (Diff VHD)" this will create a new boot entry and assign a Guid to it
• bcdedit /set {guid_of_copy} device vhd=[C:]\windows7.diff.vhd
• bcdedit /set {guid_of_copy} osdevice vhd=[C:]\windows7.diff.vhd
• bcdedit /default {guid_of_copy}
10. Boot to your new diff vhd and test away

However, this feature unfortunately created a problem which we didn't notice before VS 2008 shipped - web sites which create a large number of dynamic documents can perform quite poorly under the debugger, and now there is no option to run your site outside the debugger. If you open solution explorer and see the document list under 'Script Documents' dance up and down, you are running into this problem.

Work around:

1. This work around requires the Silverlight 2 Tools for Visual Studio 2008 SP1 to be installed. So if you don't have these tools installed, you can download them from Microsoft (https://www.microsoft.com/downloads/details.aspx?familyid=C22D6A7B-546F-4407-8EF6-D60C8EE221ED&displaylang=en). If this is not an option for you, there is some alternative work arounds at the bottom of this blog post.
2. Right click on your project and open up project properties
3. Go to the 'Start Options' sheet, and click the 'Silverlight' button at the bottom of the screen. Because the debugger cannot debug both Silverlight code and Script code at the same time, this will disable Script debugging and therefore avoid the problem.

Request for feedback:

If you want to disable script debugging, I would love to hear about your scenario. We are aware of the performance issues with applications that create many documents. We hope to address this in a future version of Visual Studio.

Alternative work around – disable all script debugging:

• Open a new command prompt (start->run, cmd.exe). If you are on a 64-bit computer this needs to be a 32-bit prompt (start->run, c:\windows\syswow64\cmd.exe)
• reg add HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {4FF9DEF4-8922-4D02-9379-3FFA64D1D639} /f

If you are using Visual Web Developer Express, replace 'VisualStudio' with 'VWDExpress':

• reg add HKLM\SOFTWARE\Microsoft\VWDExpress\9.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {4FF9DEF4-8922-4D02-9379-3FFA64D1D639} /f

If you want to restore your computer so that you can debug scripts again:

• reg add HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {170EC3FC-4E80-40AB-A85A-55900C7C70DE} /f

Work around for performance problems caused by 'anonymous code' nodes:

Some sites run into problems being debugged due to numerous "anonymous code" nodes in solution explorer. For these sites, instead of disabling script debugging completely, it's possible to disable just the 'anonymous code' nodes. This requires Visual Studio 2008 SP1. To do so:

• reg add HKCU\Software\Microsoft\VisualStudio\9.0\Debugger /v HideAnonymousScriptCodeNodes /t REG_DWORD /d 1 /f

There is currently an issue in VS 2005 after you install IE8 where script debugging is broken. If you are using VS 2008, this will not be a problem.

Brad Sullivan posted the work around in the debugger forum. Here is what he said:

IE 8 has a feature called Loosely-Coupled Internet Explorer (LCIE) which results in IE running across multiple processes.
https://www.microsoft.com/windows/internet-explorer/beta/readiness/developers-existing.aspx#lcie

Older versions of the Visual Studio Debugger get confused by this and cannot figure out how to attach to the correct process.  You can work around this by disabling the process growth feature of LCIE.  Here's how:

1)  Open RegEdit
2)  Browse to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet Explorer -> Main
3)  Add a dword under this key called TabProcGrowth
4)  Set TabProcGrowth to 0

Note that If you are using a 64-bit computer, you want to edit the 32-bit registry.

In addition to this, IE's installer will re-disable script debugging. So you will need to reenable it:

1. Open Internet Explorer
2. Go to Tools->Internet Options
3. Switch to the Advanced tab
4. Uncheck 'Disable script debugging (internet explorer)'

One finial note - if you are attempting to debug a browser extension or ActiveX control written in native or managed code, you may experience the same problem. This will happen on all OSs with VS 2005, and on XP/Server 2003 with VS 2008. In this situation, you need to follow Brad’s work around.
 

[July 10th Update]: We recently discovered another issue with Script Debugging after installing IE8. The issue does not always repro, which is how we missed it, but there is a workaround. To work around:

1. Install Visual Web Developer 2008 Express Edition, which is a free download from https://www.microsoft.com/express/vwd/Default.aspx.
2. Optional step: Uninstall Visual Web Developer express

This will update the Visual Studio shared script debugging files (the files shared between every version of Visual Studio to enable script debugging) from the Visual Studio 2005 version to the 2008 version, and will thus work around the issue.

Just My Code

The first step to understanding this dialog is to understand a feature called 'Just My Code' (enabled/disabled with 'Tools->Options->Debugging->Enable Just My Code'). Just My Code is currently a managed-only debugging feature. When enabled, the debugger divides up all the code running in the debugged process into two groups - your code, and non-user code (system code). It then tries to hide the details of system code from you so that you can concentrate on looking at your own code.

User-Unhandled Defined

Next concept to explain: 'User-Unhandled' exceptions. An exception becomes 'User-Unhandled' after:

1. An exception travels through your code  (your code either throws the exception or calls into system code which throws an exception back to you)
   -and-
2. Your code doesn't catch the exception
   -and-
3. The exception is caught by system code

In other words: 'User-unhandled' does not necessarily mean that your app is actually crashing. The debugger is trying to tell you about an exception which is probably interesting before this exception is swallowed up by the system. After catching the exception, the system might fall over and die, or it might be totally expected (in which case you should go to Debug->Exceptions and turn off stopping on 'User Unhandled' exceptions for your app).

Example: You are building a WinForms app which has a bug in its handler for some button which will cause it to deref null. If you run this app outside of a debugger, and then attach the debugger, WinForms will quietly swallow the exception. But if you have 'User unhandled' exceptions enabled, the debugger will stop and you can easily find out what went wrong.

Now to the dialog

Now that we have the concepts, let's explain how they are expressed in the dialog.

For exceptions that don't support Just My Code (C++ Exceptions, Managed Debug Assistants, Win32 Exceptions, Common Language Runtime Exceptions if Just My Code is disabled) – the debugger will show the 'User-Unhandled' checkbox as checked and disabled. What this is trying to tell you is that this setting is 'N/A'. For this type of code, the debugger doesn't divide the world up into user code and non-user code. So an exception could never go user-unhandled.

For these exceptions, the 'Thrown' column has the same meaning that it does in other debuggers (WinDbg calls this 'first chance', VS 2002/3 referred to this as 'Break' instead of 'Continue').

For exceptions Common Language Runtime Exceptions (with Just My Code enabled): Both the 'Thrown' and 'User-Unhandled' column can be checked. 'User-unhandled' has the meaning discussed above. Checking 'Thrown' will cause the debugger to stop when either user code throws the exception, or when system code throws the exception back to user code. In other words, the debugger will not stop for internal exceptions within the system code.

What about unhandled exceptions? The debugger always stops on unhandled exceptions since the process will otherwise exit. Since the debugger always stops, there doesn't need to be a checkbox for this one.

Here are the two easiest solutions:

#1: Windows includes registry settings under the ‘Image File Execution Options’ key that can help you debug this. I blogged about this before back in February of 2005 (https://blogs.msdn.com/greggm/archive/2005/02/21/377663.aspx). Most of the information is that blog is still correct. A few updates worth mentioning though:

• Visual Studio 2008 can support session 0 processes on Vista or Server 2008.
• Visual Studio 2008 can support 64-bit operating systems. The only remaining 64-bit restriction is that 64-bit managed processes cannot be debugged this way since the .NET Framework does not support managed+native debugging of 64-bit processes.
• Visual Studio 2005 does not support this feature on Windows Vista or Server 2008. You will need to upgrade to 2008 for these operating systems.

#2: You can add code to your app to cause it to pause waiting for a debugger to attach. I am attaching an example header file for making this work. We ship several executables that embed similar code for this reason. Just call ‘RuntimeDiagnostics::CheckPauseOnStartupOption()’ as the first line of code in your main routine. You can do something verify similar for managed code as well. Just call ‘System.Diagnostics.Debugger.IsAttached’ instead of IsDebuggerPresent.

int _tmain(int argc, _TCHAR* argv[])

{

    RuntimeDiagnostics::CheckPauseOnStartupOption();

    return 0;

}

Then set this registy key if you need your app to pause:

RuntimeDiagnostics.h

Visual Studio has provided ‘Script’ debugging for a long time. In this context, ‘Script’ refers to script run by jscript.dll or vbscript.dll such as the script code in Internet Explorer, classic ASP scripting, or the cscript/wscript programs. Long long ago, someone provided a sample for creating your own script debugging utilizing the active script debugging interfaces (ex: IRemoteDebugApplication).

However, this sample relied on a Microsoft executable called mdm.exe (IMachineDebugManager/CLSID_MachineDebugManager). After Visual Studio 2003, Visual Studio stopped shipping mdm.exe. So today, I wanted to provide a brief summary of how one could port an mdm.exe-based script debugger to the newer interfaces. Mdm.exe provided essentially two related features -- it allowed a debugger determine what script applications where currently running, and there was an eventing interface that let a debugger be informed when a new script application started. These features worked because the debugger component inside of the target process (pdm.dll) would connect to mdm.exe whenever a new script application was created.

Today, these features have been moved to pdm.dll. So now, pdm.dll is loaded in both the debugger and in the target process. In the target process pdm.dll still continues to do the same work as it has always done. However, now one can also load pdm.dll into the debugger process to obtain the old MDM features.

PDM now has a new CLSID for the work that it does in the debugger process – CLSID_MsProgramProvider. It exposes an AD7 interface for obtaining this information: IDebugProgramProvider2.

There is sample code attached to this blog which demonstrates how to launch or attach to a program using these new interfaces.

ScriptWithoutMdm.cpp

Sometimes Visual Studio crashes. It would be nice if this wasn’t the case, but unfortunately it happens. However, like many Microsoft applications, Visual Studio has Error Reporting so that when a problem happens, you can tell us about it in one click. However, sometimes you would like to actually tell a live human about your crash. There are a number of advantages to doing so:

1. A human might be able to tell you about a work around that Windows Error reporting doesn’t know about.
2. A human can tell you if this crash was something that we could diagnose.
3. It helps to make sure your issue is really fixed. When a developer at Microsoft looks at a Windows Error report, all we see is where the crash happened and some local variables. Sometimes we can figure out what was happening and create a repro to confirm our fix. This is the best case, but it often doesn’t happen this way. More often we need to either guess what a fix is but not test the fix, or we are unable to even guess what a correct fix might be.

For these reasons you might want to also report the issue through the Visual Studio product feedback center.

What to do

Step #1: Go to https://connect.microsoft.com/site/sitehome.aspx?SiteID=210 and enter a bug.

Step #2: In the bug, include the ‘bucketing information’. You can find this information by:

• Open the event viewer (Right click on Computer and go to ‘Manage’; click on the ‘Event Viewer’ tree item).
• Open the ‘Application’ section
• Look for the entry that happened about the correct time and had the source set to ‘Application Error’
• Copy the content and paste it into the bug, it should look something like:

Faulting application devenv.exe, version 9.0.30428.1, time stamp 0x4815597f, faulting module scriptle2.dll, version 9.0.21022.8, time stamp 0x47317e18, exception code 0xc0000005, fault offset 0x0000328c, process id 0xfbc, application start time 0x01c8bc39887cac69.