Home Dashboard Directory Help
Search

"Load dll exports" NOT working for VS2012 by Trout.Z


Status: 

Active


2
0
Sign in
to vote
Type: Bug
ID: 777848
Opened: 1/30/2013 1:36:03 AM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description

I'll grab my description from ms forum(http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/cd892053-575d-4ac0-9cf6-89d127676795):

I've encounter a crash dump analysis involving "nvd3dum.dll" which I think is part of nvidia's display driver, and thus no symbols for it. I'd like to use the dll exports to help as much as possible.

During the process, I've found vs2012 is not working properly against this feature .

I happen to have a lot of debuggers installed on my win 7 sp1 x64,thus I tried:

1 vs 2008 sp1/2010 sp1, toggle Tools->Options->Debugging->Native->Load DLL exports, and relaunch debugger session, I DID see more symbols

2 windbg after ".ecxr;kb" it automatically make use of dll exports in this case,"ERROR: Symbols file could not be found. Defaulted to export symbols for nvd3dum.dll"

3 vs 2012 update1, toggle Tools->Options->Debugging->General-> Load dll exports(Native only), (the place is changed, and seems "Enable RPC debugging" no longer exist), no matter I relaunch the debugger session or even the devenv process, it just DOESN'T show any difference(I mean additional symbols from dll exports)
Details
Sign in to post a comment.
Posted by Trout.Z on 2/5/2013 at 11:42 PM
Thx, your solution worked, and I'm OK with solution as you are in the process of totally removing this feature.
Posted by Microsoft on 2/4/2013 at 11:16 AM
Hey Trout,

Thanks for contacting us. Unfortunately, this is an intentional change in VS 2012. Previously, we were at best guessing about the dll exports and were providing incorrect data more often than not in the callstack window. We made a decision to remove this as we felt not having the info at all was better than incorrect information. The dll export data should be accurate if used in expressions or conditional breakpoints.

If you want to return to the old behavior, you can enable native edit and continue in the debugger tools->options settings. This should have the side affect of swithcing you back to the old behavior.

Sorry for the inconvenience.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Microsoft on 1/30/2013 at 7:03 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 1/30/2013 at 1:50 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)
Sign in to post a workaround.