03 February 2011

The (current) Bane of my Existence


Yes, Microsoft Visual Studio 2005, I'm looking at you.

Whenever I try to run the Clone Wars Adventures AdminClient in the debugger, I have about an 80% chance of seeing this:

This is a debug build. I most assuredly have debug symbols turned on:
And I'm not the only one to ever have this problem. People have also reported this problem on VS2008.

Oddly enough, no one else on my team has been complaining about this problem. When I start VS2005, I can generally run the client in debug once or twice and then I perpetually get this error.

Sometimes, exiting VS2005 and killing mspdbsrv.exe followed by a restart of VS2005 usually allows me to run a couple more times. However, with our huge solution (112 projects), this takes a few minutes or so. Definitely not conducive to small changes.

Some of the links above have responses from MS folks who state that they aren't able to reproduce the problem, but there is most definitely a problem.

I've only experienced this problem on our internal AdminClient, which, unfortunately, is the project that I'm most often trying to run. Other projects in the solution file seem to work just fine. I've tried several suggestions from the above links, including others like replacing dbghelp.dll with the latest version, altering the symbol search paths, trying to manually load symbols, and so on.

As a last-ditch effort, some of the links above suggest re-installing VS2005. I'll give that a shot.

If that doesn't work, I may have to become a Pirate or something.

Update: (3/23/2011): I believe I have found a work-around by using the Remote Debugging Monitor. More info in this post.

5 comments:

Unknown said...

I get it man. I have to use the same tool (luckily, sometimes VS2k8 as well), and get the same error pretty often.

There is a "kind of" workaround that "sometimes" works, and it's manually loading the modules through the debug menu. You have to do that every time you launch it and get the error, but it CAN work. YMMV of course.

And if you go the pirate route, I live in Saskatchewan, so I'll wave as you sail by!

Anonymous said...

You might try using Process Monitor to see what exactly visual studio is trying to do there... maybe it's locking the symbol files in one thread, but never releasing it?

A (crazy) alternative workaround, in case it is a filesystem related problem: you could install a symbol server.

Joshua Kriegshauser said...

I tried the Process Monitor route (love that tool) and actually managed to crash it every time I set the filters to devenv.exe and mspdbsrv.exe.

The symchk utility reports that the exe and pdb match (no surprise there). And the application itself will load symbols with DbgHelp.dll and has never failed to load the pdbs (even when passing SYMOPT_EXACT_SYMBOLS to SymSetOptions).

Neither devenv.exe nor mspdbsrv.exe actually had dbghelp.dll loaded when I attached to them with WinDbg, so there's either another process that acts as the debugger or VS2005 uses a different symbol load method entirely.

The only workaround that I've found to work generally is to run the Remote Debugger on the same machine and connect to the Remote Debugger. It's not super fast, but as long as it keeps working...

Joshua Kriegshauser said...

@Eriol I've tried loading the symbols manually too. No dice. And the error message just says something to the effect of 'symbol file doesn't match executable' even though symchk says that they do match.

/boggle.

Looks like it might be time to get the Jolly Roger and sail it along Regina's mighty shores.

Mindeen said...

I've had the same issue whenever any of the underlying solution directories changed in some way, not sure if it is the same issue. I rebuild the entire solution and the issue goes away permanently usually. Maybe the the versioning control software you use is causing the issue?