Friday, April 17, 2009 4:47 PMIs there a reference page anywhere for mspdbsrv.exe? I work with a very large solution in visual studio 2008, and often get the error that debug symbols can not be found. Closing visual studio, killing mspdbsrv.exe, and restarting visual studio fixes this problem. Closing visual studio and reopening the solution is quite slow, however, so I would like to see if just killing and restarting mspdbsrv.exe will fix the problem. I tried executing C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\mspdbsrv.exe, but it returns immediately and does not add an entry to the task bar. I can't figure out what arguments I need to pass it to start it up in the same way that visual studio (or perhaps cl.exe?) does.
Friday, April 17, 2009 6:37 PMModeratorThere is no documentation for it, it is meant purely as an internal helper for the compiler. It ensures access to .pdb files is properly serialized in parallel builds when multiple instances of the compiler try to access the same .pdb file. It runs as a service so can't be started from the command line. It can't slow down loading of projects since it is only used while compiling.
It's been a troublemaker, early releases suffered from handle leaks. Most, but not all, of these problems were solved, be sure to download and install service pack 1. I only have to kill it occasionally nowadays. If the SP doesn't solve your problem, you'll need to call MSFT directly for support.
- Marked As Answer by nobugzMVP, Moderator Saturday, April 25, 2009 11:29 AM
Friday, April 17, 2009 8:46 PMThanks for the reply, Hans. We're still getting the "Debugging information for '<process>' cannot be found or does not match. Symbols not loaded." dialog box all the time, and we're on SP1 already. I don't think calling MSFT will be useful, since I don't have a reproduce case other than giving them my whole project and telling them to try working with it for a few hours.
A coworker here was able to find the commandline, though, by using process explorer, which will tell you the commandline that launched any process. The commandline for mspdbsrv.exe is apparently:
mspdbsrv.exe -start -spawn
By using another feature of process explorer - look for strings in a library - he was able to find all the commandline switches:
-start, -spawn, -verbose, -log, -stop, -shutdowntime, -priority, -endpoint, -cachetime
This answered the question I asked, but alas did not solve my problem; I tried launching mspdbsrv.exe this way, and it worked fine if I close visual studio and restart after running mspdbsrv, but it doesn't work if I start it after visual studio is launched. I guess VS must register itself with mspdbsrv when it starts, so there's no way to fix the problem other than closing and restarting visual studio.
Friday, April 17, 2009 9:44 PMModeratorYour problem isn't caused by mspdbsrv.exe. The debugger simply has a problem finding the correct .pdb file. Your first diagnosic is to single-step into your program, Debug + Windows + Modules, right-click your .exe and choose Symbol Load Information. It shows you where it searched for the .pdb file, check if they are there and were created by your last build. Beyond that, check if all the debugging command line options are set correctly.
BTW, Microsoft support gladly takes an entire project to troubleshoot a problem. I sent one in that kept one of their programmers busy for two weeks, diagnosing a nasty vb6 build system problem. Anything that reproduces the problem is worth 1000 times a mere description of a problem. Your IP is safe. You'll get your money back when it was their mistake. I did.
Sunday, April 19, 2009 6:18 PMBy "all the time" I mean frequently, not literally every time we run. It works fine at first, but then after a few steps of editing and recompiling, we will get the error, and have to fix it with a kill mspdbsrv.exe and restart. I'll try your diagnosis suggestion the next time it happens.
That's an interesting suggestion about using MSFT and paying for them to solve the problem; I was assuming you were talking about standard support channels like these forums or email@example.com. I'll look into sending the problem off to MSFT, thanks!
Saturday, July 25, 2009 6:48 PM
Title: You may receive a "PRJ0008" or "C2471" or "C1083" or "D8022" or "LNK1103" or similar error message when you try to build a solution in Visual C++
- D8022 : Cannot open 'RSP00000215921192.rsp'
- PRJ0008 : Could not delete file 'vc90.idb'.
- C1083 : Cannot open program database file 'vc90.pdb'
- C2471 : Cannot update program database 'vc90.pdb'
- LNK1103 : debugging information corrupt.
This problem occurs when all of the following conditions are true:
- You have a solution with more than one project in it.
- Two or more of the projects are not dependent on each other.
- You have parallel builds enabled. (Tools -> Options: Projects and Solutions, Build and Run: "maximum number of parallel project builds" is set to a value greater than 1)
- You are building on a system with multiple CPUs (cores).
- Two or more of the non-dependent projects are configured to use the same Intermediate and/or Output directory.
- A specific race condition in mspdbsrv.exe remains uncorrected.
To resolve the problem do one or more of the following:
- Reconfigure the non-dependent projects to specify an Intermediate and Output directory that is different from one another, e.g. Output Directory = "$(SolutionDir)$(ProjectName)\$(ConfigurationName)", Intermediate Directory = "$(OutDir)".
- Adjust your solution's project dependencies (Project -> Project Dependencies...) so that each is dependent on another.
- Disable parallel builds.
- Add the "/onecpu" boot option to your boot.ini file.
- Change you BIOS settings to enable/use only one CPU.
- File a problem report with Microsoft Technical Support and keep bugging the ____ out of them until they eventually fix mspdbsrv.
The problem is a combination of both a user project configuration error as well as a race condition in Microsoft's "mspdbsrv.exe" utility that does not properly handle more than one thread calling it at the same time for the same file resulting in the file's HANDLE being left open.
Additionally Visual Studio itself and/or its build system (VCBUILD and/or MSBUILD) (or all three!) should be made smart enough to detect and alert the user of such user errors so that corrective action can be taken.
This problem has been around for a LOOOOOONG time.
- Microsoft Visual C++ 2005
- Microsoft Visual C++ 2008
"Fish" (David B. Trout)
You're welcome. :)
Fish (David B. Trout)
- Proposed As Answer by Fish Fish Saturday, July 25, 2009 6:48 PM