2

We are trying to debug through a SQL Server Compact 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 resources around the Internet, we set the options:

  • Symbol Server = http://referencesource.microsoft.com/symbols
  • Menu Tools -> Options -> Debugging -> Just My code = Disabled
  • Menu 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 Compact symbols have loaded and when we click the details on the error dialog, we get a message indicating that the SQL Server Compact 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, Visual Studio 2008 SP1 .NET Framework Source Debugging.

However, I cannot find anything official about this issue. Is there anything I'm missing? Is it true that Windows 7 symbols are being incorrect. If so, when will they be updated?

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 it claims there is no source code at the location.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Brian Ellis
  • 1,829
  • 1
  • 19
  • 24
  • .NET Mass Downloader also fails on Windows 7, http://www.codeplex.com/NetMassDownloader so your assumption is proven to be true. Why you need an official word on that? Windows 7 is not yet general available. – Lex Li Sep 17 '09 at 07:06
  • 1
    It's good to see other evidence pointing to that being true. However, Windows 7 Enterprise is widely available to business users, which I assume many .Net developers are. Therefore, I don't think it's asking too much to get an official word on whether source debugging is broken or not, and if so, when it will be fixed. – Brian Ellis Sep 21 '09 at 15:15

2 Answers2

1

My guess is that your DLL files 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 the 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 application, 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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Steve Cooper
  • 20,542
  • 15
  • 71
  • 88
0

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
  • 20,542
  • 15
  • 71
  • 88