fatal error LNK1201: error writing to program database 'project.pdb'

[onkelhotte]

Hi there,
my colleague and I have an error message

fatal error LNK1201: error writing to program database 'C:\Users\ulso\Documents\Visual Studio 2010\Projects\DFC\bin\DFC_Kernel.pdb'; check for insufficient disk space, invalid path, or insufficient privilege

since a few days. We have to close Visual Studio completely (not just closing the soulution) and delete this file manually. Of course this happens not all the time, there is enough disk space, the path is correct and we have sufficient privileges...

Has anyone seen this behaviour before?

Thanks in advance,
Markus 

[Steven_L_Intel1]

Try temporarily disabling antivirus software or tell it to exclude your project folder from its searching. I assume there is only one project being built at a time?

[onkelhotte]

Hi Steve,

I can´t disable our McAfee antivirus nor configure it. There are nine projects in this solution and the one that creates that error depends on other projects and it is used by other projects.

Markus

[Arjen_Markus]

I think Steve refers to the option in Visual Studio to build projects in parallel. What happens if you set that option to 1 (that is: only one build process at a time)

This option is found in: Tools/Options/Projects and solutions/Build and Run

Regards,

Arjen

[onkelhotte]

This setting was 4. Changing it to 1 didn´t help.

But I figured out I have just to close VS and don´t have to delete it manually. A little less annoying, but it still is. So it seems to be a VS problem and not a IVF problem...

Markus

[FortranFan]

I too get this error in Visual Studio 2012 and agree with Markus: it is a little annoying, it seems to be a problem with Visual Studio 2012, and one possible work-around is to shutdown Visual Studio and restart it.  It seems to happen to mostly when a debug session is interrupted e.g., due to a run-time exception.

The reason I feel this is specific to Visual Studio 2012 is because the same solution works ok with Visual Studio 2010; Intel Fortran compiler and the IDE integration is the same is both versions of Visual Studio.

Anyone know if this issue has been resolved in Visual Studio 2013?

[Steven_L_Intel1]

I see this from time to time myself, and restarting VS2012 seems to be the only solution. I haven't used VS2013 enough to say whether the bug is fixed there.

[ZlamalJakub]

I think this issue is connected with the debugger. It sometimes does not close pdb file when it finishes. It occurs to me very often if my program crashes (especially if the problem is in dll) or I stop debugger while debugging. Problem does not occur if the program exits correctly.

But I must say that this problem that the frequency of this problem is very small in new versions of Developer Studio.

[rase]

The problem occurs once in a while, but I am not sure if it is connected with debugging. I'll keep an eye on it when I use debugging. Restarting VS helps anyway.

[Steven_L_Intel1]

The only time I see this is if I ran the program under the debugger before the next build - but then not always. It doesn't matter how the program terminated. Quba is correct that VS is holding the PDB open when it shouldn't - probably it has lost the handle and the only way to recover is to restart VS. I can go for weeks without seeing this and then it won't go away all day...

[FortranFan]

As I mentioned earlier, the problem occurs for me when Visual Studio 2012 retains a lock on the program database file, almost always from an abruptly terminated debug session.  This lock issue does not occur for me with Visual Studio 2010.

One solution that works well for me with Visual Studio 2012 is explained here.  Note it involves installing the LockHunter freeware, hence beware of the consequences of doing so in your computing environment:

user1011648 said:

I have finally found a workaround solution for this problem that has been plaguing me for quite sometime:

1) Download and install LockHunter (free utility to unlock locked files):    

http://lockhunter.com/download.htm

2) Add the install directory of LockHunter to your environment variable "path" to avoid annoying administrator privilege popups every time you run the utility.  For me (using x64 version) it was:       "C:\Program Files\LockHunter"

3) Add the following pre-build event to your Visual Studio project that is experiencing the issue:

       "C:\Program Files\LockHunter\LockHunter.exe /silent /unlock $(TargetDir)$(TargetName).pdb"

Cheers,

[tsimm3 · Accepted solution]

I've had this problem for years. It apparently goes back to VS 2003. I use the freepdb.cmd described in this article. Maybe does the same as LockHunter. It works for me.

http://social.msdn.microsoft.com/Forums/vstudio/en-US/b0271379-3ab1-4e08-af9e-d4f51fe8de79/lnk1201-error-at-every-build?forum=vclanguage

[onkelhotte]

Thanks tsimm for the hint!

[Andrew_Smith]

I confirm this issue is present in VS2013. I too was using FreePDB in VS2008 and earlier but the issue seamed to go away in VS2010.  I have been using VS2013 for a few days now and I had to do several re-starts today. I installed VS2013 Update 1 today so maybe it is connected with that.

[George_P_]

I have just run into this problem when testing a new program using the Intel Fortran compiler in VS2012 and, as far as I can determine from the above and other searches there is no solution.

I am positively amazed that, unless I am mistaken, an annoying and time wasting bug such as this should have persisted for over a decade.

[rase]

After installation of Composer XE 2015 the problem with the pdb file resurfaced again, in new projects and much more frequent than previously, I am not sure if I have to blame myself by setting up the new projects in a disorderly manner. Has anybody else made the same observation with the pdb files after installation of Composer 2015?

[FortranFan]

I don't see any evidence that Composer/Parallel Studio 2015 has made the problem worse.  In fact, my contention remains this is a Visual Studio issue that is being ignored by Microsoft.

Anyways, I continue to use the LockHunter solution I described in Quote #11 above and I don't see any issues with Fortran projects; I still encounter some problems with my C/C++ projects but I've not investigated why they persist.

[andrew_4619]

After several years on VS2010, I installed VS2013 recently and have since had this problem a few times. Quite irritating you would think it would have been fixed by now Mr Gates.

[andrew_4619]

This become quite frequent and annoying in the last couple of days so I did the lockhunter solution from #11. One problem is UAC which always prompts to allow lockhunter to run and thus gives a few seconds delay. The quote from stackover flow said "2) Add the install directory of LockHunter to your environment variable "path" to avoid annoying administrator privilege popups every time you run the utility.  For me (using x64 version) it was:       "C:\Program Files\LockHunter" " but I don't see how that helps. I did that any it makes no difference, this issue I think is because lockhunter can write to the registry it needs security promotion by UAC. Other than switching of UAC (which has some benefits I do not want to lose) does anyone have a solution?

Running W7 x64 by the way

[FortranFan]

app4619 wrote:

This become quite frequent and annoying in the last couple of days so I did the lockhunter solution from #11. One problem is UAC which always prompts to allow lockhunter to run and thus gives a few seconds delay. The quote from stackover flow said "2) Add the install directory of LockHunter to your environment variable "path" to avoid annoying administrator privilege popups every time you run the utility.  For me (using x64 version) it was:       "C:\Program Files\LockHunter" " but I don't see how that helps. I did that any it makes no difference, this issue I think is because lockhunter can write to the registry it needs security promotion by UAC. Other than switching of UAC (which has some benefits I do not want to lose) does anyone have a solution?

Running W7 x64 by the way

I run Visual Studio as administrator (my shortcut link has "Run as administrator" box checked) and I don't have the UAC problem. 

[andrew_4619]

FortranFan wrote:
I run Visual Studio as administrator (my shortcut link has "Run as administrator" box checked) and I don't have the UAC problem. 

D'oh! Simples! That would work, cheers.

I came up with a scheme to set a window task scheduler item to run lockhunter with elevated privilege,and then created a shortcut to run the task scheduler event, this get around UAC. It sort or works but you have to hard code the pdb file in the event as I could not see a way to pick up the VS file descriptor token. It also seems like a sledge hammer to crack a nut, but interesting to know.

I am now thinking that lockhunter puts a maybe 7 second delay in every build and given the lowish frequency of the glitch it is probably quicker to just right click on the pdb file and pick the unlock action on the times it does lock up.

Either way the unlocker is miles better than have to close and reopen VS.