Managed Minidump Debugging in SP1 - by Philip Stears - DriveWorks

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


17
0
Sign in
to vote
ID 650348 Comments
Status Closed Workarounds
Type Bug Repros 13
Opened 3/9/2011 3:32:53 AM
Access Restriction Public

Description

I'm unable to start managed minidump debugging using Visual Studio 2010 with SP1 applied. 

The following message is logged to the Debug section of the Output window in Visual Studio:

Managed Minidump Debugging: The debugger was unable to find or download version 4.00.30319.1 of 'mscordbi.dll'.
Sign in to post a comment.
Posted by Philip Stears - DriveWorks on 4/25/2011 at 10:36 PM
Thanks!
Posted by Microsoft on 4/22/2011 at 12:41 PM
My appologies on the delay. As "thealexdresko" pointed out below, it shouldn't have been so hard to get this working. Unfortunately it did. Sorry about that.

It should be working now.
Posted by oliverbock on 4/19/2011 at 9:21 PM
In my case the dump comes from an Azure server, so I cannot log in and grab the files.
Posted by Samuel_1_3 on 4/13/2011 at 4:09 AM
The suggested workaround does its job in my case...
Posted by thealexdresko on 4/7/2011 at 9:05 AM
Awwwww, I was SO hoping to show our developers a new technique for debugging customer issues with our applications, but can't because of this issue. How hard can it really be to add "a few files" to the public symbol server?
Posted by molesmoke on 4/1/2011 at 7:56 AM
I'm experiencing this issue, and the suggested workaround below doesn't work for me.
Posted by Microsoft on 3/21/2011 at 6:22 PM
Thanks for reporting this issue to us. It appears that a few files which should be present on the public symbol server haven't gotten there yet and we are working to resolve this as soon as possible. Once the files are available I anticipate the issue will vanish. Apologies for the inconvenience. In the meantime this workaround may get you up and running more quickly:

1) Log on to the machine which produced the dump (or any machine that has the v4.0 RTM version, 4.0.30319.1, of .Net Framework installed).
2) Collect the following files:
%windir%\Microsoft.Net\Framework\mscordbi.dll
%windir%\Microsoft.Net\Framework\mscordacwks.dll
%windir%\Microsoft.Net\Framework64\mscordbi.dll
%windir%\Microsoft.Net\Framework64\mscordacwks.dll
3) Share or copy those files so they are accesible to the machine where VS SP1 is running
4) From VS, add the path to those files in your symbol path

Hope this helps,
-Noah Falk
Posted by benthom on 3/11/2011 at 10:56 AM
I'm running in to this as well.
Posted by Andrew Zakharkin on 3/10/2011 at 9:18 AM
I'm experiensing this problem too. My process (64bit) has been dumped from Win2k3 R2 machine with CLR 4.0. My debugging machine is Win7 64, Visual Studio 2010 SP1.
Posted by Microsoft on 3/9/2011 at 5:59 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.


Posted by Microsoft on 3/9/2011 at 4:13 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)