views:

254

answers:

3

We are trying to debug through a Sql Server CE issue on a Windows 7 Enterprise RTM (64-bit) desktop running the .Net Framework 3.5, SP1. The application is crashing consistently and we are trying to set up .Net Framework debugging for Visual Studio 2008, SP1. Using the scattered resoures around the internet, we set the options:

  • Symbol Server = http://referencesource.microsoft.com/symbols
  • Tools->Options->Debugging->Just My code = Disabled
  • Tools->Options->Debugging->Enable .Net Framework Debugging = Enabled
  • Tools->Options->Debugging->Enabled Source Server Support = Enabled

When we run the application, we are unable to step into the source and we still get the error "There is no source code at this location." We do get the stack trace indicating that the Sql Server CE symbols have loaded and when we click the details on the error dialog, we get a message indicating that the Sql Server CE pdb file was loaded correctly.

I did find a blog post indicating that this is an issue with the symbols not being updated for Windows 7 yet here: http://software.intel.com/en-us/blogs/2009/09/07/visual-studio-2008-sp1-net-framework-source-debugging/

However, I cannot find anything official about this issue. Is there anything I'm missing? Has anyone heard anything about Windows 7 Symbols being incorrect and/or when they will be updated? Thanks in advance.

UPDATE 1: Added that my Windows 7 build is 64-bit. We also just tested this same scenario on Windows Vista 64-bit and received the same problem and error. It says that it loaded the pdb but claims there is no source code at the location.

A: 

Are you using the 64-bit version of the debugger?

steve
I'm using the standard Visual Studio Debugger. I did not install any extra components so I am assuming that I am using the 32-bit debugger with Visual Studio (which is 32-bit).
cisellis
i'm having similar issues just simply trying to debug in visual studio 2008 under windows 7 64bit...was there a reason for your question relating to it?
Doug
A: 

My guess is that your DLLs are release build, and so the JIT compiler is optimising away some of the function calls (it often inlines small functions). That means that when th runtime tries to translate from the jitted code back to the PDB, it gets confused.

Try adding an .ini file to your application root; so if your app is prog.exe, add prog.ini with the following content;

[.NET Framework Debugging Control] 
GenerateTrackingInfo=1
AllowOptimize=0

This will stop the JIT compiler from optimising away the calls, and let your PDB files refer to the correct calls in your code. You'll need to restart the app, and because it's running without optimisations, it'll slow it down to DEBUG build levels, but you should be able to attach the debugger correctly.

Steve Cooper
Thanks but they were definitely debug dlls.
cisellis
A: 

In the project build properties, there is an option to choose which architecture to run on - x86 or x64. You might try switching to x86 for debugging purposes; it may allow you to debug and find your problem.

Steve Cooper