I keep getting this error message as a result after every Debug run I have done on any of my projects in VS2003.
I have browsed around many forums and they all provide an answer that does not fit to the actual problem.
LINK : fatal error LNK1201: error writing to program database 'd:\Coding\Flyff\Projects\GUI System 20110721\Debug\GUI System 20110721.pdb'; check for insufficient disk space, invalid path, or insufficient privilege
I'm using Windows 7 Ultimate x64 with Visual Studio 2003 .NET (service pack VS7.1sp1-KB918007-X86.exe).
What I have tried already:
Run in compatible mode for several other operative systems and service packs.
Set project folders write permission to full.
Run Visual Studio as Administrator.
Edited Debug Information Format to several other formats.
To reproduce this bug, you must have Windows 7 x64 (probably Ultimate).
Visual Studio 2003 (with VS7.1sp1-KB918007-X86.exe update).
I have over 150 GB space so it has nothing to do with that.
Visual Studio simple locks the PDB file when debugging, and after debug it cannot unlock it.
You must also run a code piece that is running for a few seconds, such as this:
int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
Sleep( 5000 );
MessageBox( NULL, "Test", "", 0 );
return 0;
}
Hope anyone have a solution, as I'm currently required to use this environment configuration.
Cheers, Nicco.
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:
"LockHunter.exe /silent /unlock $(TargetDir)$(TargetName).pdb"
The only time I have encountered this issue with VS2003 is when it crashes during a debug session. Usually the problem can be remedied by restarting VS. If that doesn't work you have to restart the debugger service and in some cases Windows.
You can try adding the following to command line of the pre-build event
net stop "Machine Debug Manager"
net start "Machine Debug Manager"
Since either VS or the debug manager is keeping the file locked I fear this problem is caused by a much deeper issue. There is a good chance that either a problem exists in your VS installation or there is another service or application causing the debug manager and/or VS to behave badly.
I encounter this error with VS2010 and tried fixing it using methods suggested in forums but they never worked for me. At the end I exited VS2010 and restarted as Admin and that did the trick!
I have the same inssue with winXP SP3 and VS C++ 2010 Express, and i solved changing the MyProject folder Access Permissions, uncheking "read-only" and apply to all folders, subfolders and files.
Non of the above answer work in my case, But finally I found my Solution.
When scale of the project grows and size of the ".pdb" file exceed 300MB, the error accrued.
I change debugging info properties in my project and successfully compile it.
You just need to change "Debug information format" in your project to "C7 compatible (/Z7)" in the following path.
Configuration properties >> C/C++ >> General >> Debug Information
Format
Had similar problem on Windows 10. This answer provides a solution using a tool called FreePDB.
Related
During a long compilation with Visual Studio 2005 (version 8.0.50727.762), I sometimes get the following error in several files in some project:
fatal error C1033: cannot open program database 'v:\temp\apprtctest\win32\release\vc80.pdb'
(The file mentioned is either vc80.pdb or vc80.idb in the project's temp dir.)
The next build of the same project succeeds. There is no other Visual Studio open that might access the same files.
This is a serious problem because it makes nightly compilation impossible.
It is possible that an antivirus or a similar program is touching the pdb file on write - an antivirus is the most likely suspect in this scenario. I'm afraid that I can only give you some general pointers, based on my past experience in setting nightly builds in our shop. Some of these may sound trivial, but I'm including them for the sake of completion.
First and foremost: make sure you start up with a clean slate. That is, force-delete the output directory of the build before you start your nightly.
If you have an antivirus, antispyware or other such programs on your nightly machine, consider removing them. If that's not an option, add your obj folder to the exclusion list of the program.
(optional) Consider using tools such as VCBuild or MSBuild as part of your nightly. I think it's better to use MSBuild if you're on a multicore machine. We use IncrediBuild for nightlies and MSBuild for releases, and never encountered the problem you describe.
If nothing else works, you can schedule a watchdog script a few hours after the build starts and check its status; if the build fails, the watchdog should restart it. This is an ugly hack, but it's better than nothing.
We've seen this a lot at my site too. This explanation, from Peter Kaufmann, seems to be the most plausible based on our setup:
When building a solution in Visual Studio 2005, you get errors like fatal error C1033: cannot open program database 'xxx\debug\vc80.pdb'. However, when running the build for a second time, it usually succeeds.
Reason: It's possible that two projects in the solution are writing their outputs to the same directory (e.g. 'xxx\debug'). If the maximum number of parallel project builds setting in Tools - Options, Projects and Solutions - Bild and Run is set to a value greater than 1, this means that two compiler threads could be trying to access the same files simultaneously, resulting in a file sharing conflict.
Solution: Check your project's settings and make sure no two projects are using the same directory for output, target or any kind of intermediate files. Or set the maximum number of parallel project builds setting to 1 for a quick workaround. I experienced this very problem while using the VS project files that came with the CLAPACK library.
UPDATE: There is a chance that Tortoise SVN accesses 'vc80.pdb', even if the file is not under versioning control, which could also result in the error described above (thanks to Liana for reporting this). However, I cannot confirm this, as I couldn't reproduce the problem after making sure different output directories are used for all projects.
Switch the debug info to C7 format instead of using the PDB.
Project Options -> C/C++ -> General -> Debug Information Format and set it to C7.
This generally happens when your previous attempts at debugging have not killed the debugger fully.
In Task manager look for a process called vcjit, kill it and try again.
Worst option restart visual studio, this should solve your problem.
I had this problem today and it turned out to be non-ansi characters in the path to the pdb that caused it.
I'm using windows through vmware, and my project was in a shared location: \vmware-host\Shared Folders\project
When I moved it to \Users\julian\project it resolved the issue.
I just ran into this problem. Visual studio was complaining about not being able to open vc100.pdb. I looked for open file handles to this file using procexp and found out that the process mspdbsrv had an open file handle to it. Killing this process fixed the issue and I was able to compile.
Try right click the excutable file of VS....and Properties->Compatibility-> Tick "Run this program in compatibilty mode for:" OFF........
I had a similar problem while working on a project which I had located in my Dropbox folder. I found that it would throw this error when the little "syncing" icon was going on the Dropbox icon in the system tray, since Dropbox was accessing the files to upload them to their server. When I waited to build until Dropbox finished syncing, it worked every time.
I have same problem C1033: cannot open program database,
Scenario
I have two dll's parent.dll and child.dll.I just attached child.dll project with visual studio debugger at the same time i am trying to build the parent.dll project,produces error C1033: cannot open program database
Solution
Stop debugging and kill the process attached with the debugger.Rebuild the project
This happens to me consistently if I Ctrl+Break to cancel a build (vs2015). There's some process that isn't shut down properly. I went on a rampage "End Tasking" ms/vs related processes (look for duplicates) and my build worked again. A restart would probably work too. As would moving to gnu binutils.
Annoyingly unlocker tools don't report any processes locking the file, windows doesn't let me delete the .pdb but I can rename it. My guess is two processes jump in at the same time during a build.
Are you using LinqToSql at all? Perhaps it is similar to the odd error I will experience occasionally as I asked in this question: What causes Visual Studio to fail to load an assembly incorrectly?
I changed my intermediate directory from:
%TEMP%\$(ProjectName)\$(Platform)\$(Configuration)\
to
C:\temp\$(ProjectName)\$(Platform)\$(Configuration)\
It works now. NO idea why.
In my case the problem was Google Drive: I forgot that the project was under a synced folder and G Drive probably locked that file. Pausing the sync didn't help since the error was throwed anyway.
Moving the project folder to another location not synced by Google Drive solved my issue.
Just to mention, at the beginning I thought it was my anti-virus, since when examinating the file using procexp it showed that the file was used by one of my anti-virus process. Excluding the folder project from my anti-virus scan didn't help in my case.
the simplest solution is "build one more time":
BuildConsole abc.sln /rebuild /cfg="release|Win32"
if %errorlevel% neq 0 (
BuildConsole abc.sln /cfg="release|Win32"
if %errorlevel% neq 0 (
rem process error
exit 1
)
)
I just ran into this problem and Google led me here. For me, it was Google Drive syncing my project files while I'm trying to run. Pausing Google Drive sync temporarily solved it, but I'd rather there was a way for Google Drive to keep its hands off while Visual Studio is doing its stuff. If anyone knows how I can configure that, please let me know
I'm writing a C++ application using VS2010 on two dev computers - both are Win7 64bit SP1. I use git to sync the repositories.
On one of the machines the compiled executable (and also the test exec) stopped working with the following error, while on the other machine it works fine and I'm able to continue development.
The application was unable to start correctly (0xc000000d). Click OK to close the application.
I tried deleting the repository and cloning it again. I also made sure I have the same versions of Boost, git, Visual Studio. Also, I tried debugging (stepping in) but the error occurs before any line of code is reached.
Notice as far as I understand I'm tracking Visual Studio's solution\project configuration files as detailed here.
I'm at a loss, how would you debug this?
UPDATE 1:
Only the Debug version fails to run. The Release version runs fine
UPDATE 2: The executable that doesn't work does work on the other computer!
UPDATE 3: I've reinstalled VS2010 (exactly the same version) - didn't help. Surprisingly the compiled files are not the same size between the two machines.
I got the same problem as you mentioned.
My solution:
Clean the manifest file and rebuild
In the property page-> Manifest tool -> make sure "Additional Options" is set to nothing.
(I set it as "/validate_manifest" before).
Or you can try "Embed Manifest -> NO", rebuild and then set back to Yes. It sounds to be ridiculous, but it really works sometimes. I don't know why.
I got the same phenomenon suddenly without a warning on Win7 / VS2010 / C++. Debug App couldn't be launched, got 0xC000000D at initializing and loading multiple dlls. Found one base dll of my own responsible, played around with linker settings. Modifying settings, incremential rebuild -> app starts, rebuild all -> app crashes again. After setting "generate manifest" to "no" in the linker settings the sample app works, but the main app still crashes. After setting "generate manifest" to "no" for the most of my dlls -> the app starts in debug mode again. The stuff is very spurious, because some dlls need the modified settings others do not.
Have a look at the top two answers to this question
Program crashes with 0xC000000D and no exceptions - how do I debug it?
On the machine where it fails, try running the debug executable NOT under the debugger, and update your question to say what happens. If it crashes, are you able to then attach the debugger whilst the message box is still there and get a stack trace that tells you what function it is crashing in?
This is the weirdest thing....
Try deleting the "ipch" directory and then rebuilding.
Hope it works for you, I have wasted hours on this.
disabling/enabling precompiled headers fixed the issue for me.
I was facing crash on Debug x64 only - I guess it was related to an upgrade from boost 1.50 to 1.52, while keeping pch files.
in my case i got it working again by setting generate manifest to NO on all projects
I have changed "Embed manifest" setting to NO and then back to YES but it didn't help.
For me setting General->Platform Toolset to Windows SDK 7.1 for my program and all dependent libraries compiled with it helped.
It's the ipch just delete the entire folder and it will clear it up. I was confused for a while too.
I saw the error while using OpenCV library compiled with MSVC2010 in a project running on MSVC2015. Changing project configuration properties->General->Platform toolset from Visual Studio 2015(v140) to Visual studio 2010(v100) resolved the error.
I'm using WMI's CreateProcess() to run an installation bootstrapper process (setup.exe) on a remote machine. The setup.exe is happily able to run .msi packages but for some reason it is not able to run the vcredist.exe packages that are used to redistribute the MS VS 2008 SP1 C++ Runtimes.
What I'm seeing is that the redist package is able to extract itself into a temp folder in the root of the C:\ drive, e.g. C:\a26f91763649ecad76a09d or some such, but after that the process hangs around.
I don't know what to do to debug further - I suspect that there is a modal dialog in the hidden windows station awaiting dismissal, but I can't see what the text is. Process Explorer isn't yielding much either.
Anyone got any suggestion? The problem applies equally in Windows 2000 as in Windows 2008. We used to use a DCOM-based method to launch setup.exe remotely and this did not exhibit the problem.
Can anyone shed any light on what might be going on, or how to diagnose further.
Many thanks,
Stephen
User error! My suspicion about the modal dialog was correct. It seems that invoking the setup.exe files with a relative path somehow caused the command line arguments to get stripped when passed to the nested exe, so they ran in full UI mode! Invoking with a fully-qualified path resolved the problem.
I'm writing a class in C++ that I cannot debug by using F5. The code will run from another "service" that will invoke it.
In the past I've used __debugbreak() and when I got a window telling me that an exception was thrown selected to debug it.
Recently I've updated to windows 7 and it kept working for a while.
Today when I've tried to debug a piece of my code instead of shown the regular dialog that tells me that VSTestHost has stopped working and enable me to to debug the application I got a different dialog suggesting I send the data to microsoft for analysis.
Does anyone knows how can I fix this issue so I'll be able to debug my code?
Finally I found the cause of the issue.
It's a Vista/Win7 cause:
Open The Action center control
Goto Action Center settings
Goto Problem Reporting Settings
Choose "Each time a problem occurs, ask me before checking for solution"
Although this is more of IT solution/question I've been plagued with this problem all day and wanted to share the solution with other developers who encounter this problem.
I finally found the solution for Windows 10/11 here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/enabling-postmortem-debugging
And also: https://learn.microsoft.com/en-us/windows/desktop/Debug/configuring-automatic-debugging
To enable automatic debugger launch, you should add a registry value:
key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug, value Auto = 1 (of type REG_DWORD)
The configured debugger is set the by the value Debugger (type REG_SZ); a Visual Studio installation sets this to:
"C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld
Note that on 64 bit OS this only works for 64 bit executables. To enable the same behaviour in 32 bit executables set the same values in this key:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
In that case...
http://community.codesmithtools.com/blogs/blake/archive/2009/06/03/tips-amp-tricks-debugging-codesmith-on-microsoft-windows-7.aspx
Here is the quick overview of what you need to-do to enable debugging on a Microsoft Windows 7 machine:
Update the Just-In-Time debugger setting DbgJITDebugLaunchSetting. The setting is found in the registry at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework].
Set the value of DbgJITDebugLaunchSetting to 2.
If you are using a 64bit operating system then you must also set the same key (DbgJITDebugLaunchSetting) in this folder [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework] to 2.
If you run into any issues try running CodeSmith Studio and Visual Studio as an administrator.
Now when CodeSmith enters a break point you will see something like this:
You could try debug > attach to process.
I've just discovered that regtlib.exe appears to be missing from Windows 7 (and apparently from Vista as well).
I've just installed Windows 7 RC in a VM and I'm attempting to build our existing projects on the new OS. The projects are c/c++ based and I'm using visual studio 2008. In order to build these projects I need to register several tlb files that are referenced within the code base.
Has anyone also encountered this problem? And, has anyone managed to solve this?
Thanks.
Yeah regtlib was removed from vista and up. As far as I know, all it does is call LoadTypeLibEx with the REGKIND_REGISTER flag (http://msdn.microsoft.com/en-us/library/ms221249.aspx). Maybe you could write a simple replacement.
Just came across this issue (couldn't add any components to a VB6 project on Win7). This post (Error accessing the system registry in VB 6 IDE) pointed to regtlib (which is missing from Win7). I just
set the VB6 start menu icon to 'Run As Administrator' and it worked fine for adding components and should fix any problems relating to updating the registry as well.
Regards
Ian
Finally got back to trying to build our code base on windows 7. Anyway, I went back to the installer for one of the dependencies that was causing me grief. The error message from the installer wasn't to helpful but it did point to a regasm that was being run from inside the installer.
I ran the regasm command from a cmd prompt and got more information. It appears that you need administrative credentials to perform this task and our current installers don't do the privilege escalation properly.
So, long story short, I got dlls registered and the build appears to be working.