I have a large project that has > 1000 files.
When I press the green 'Play' button to start debugging, once everything is built, it can take up to 5 minutes for the app to start running.
It looks like Visual Studio is loading and unloading various DLLs, but it also just sits there occasionally doing nothing.
Running from the command line takes only a few seconds.
What's going on? How can I speed it up?
[EDIT] It turned out to be our Symbol Server. The administrator had killed it without informing anyone. Doh.
Thanks for your help guys.
Some thoughts and suggestions:
It could be caused by complex dependency checking that VS2005 does to ensure that no components have changes and have to be re-built prior to debugging. Sometimes tweaking the inter-project dependencies in the solution can help.
Are you using source control integration in Visual Studio? If so, sometimes accessing the source control repository elsewhere on the network can cause Visual Studio to slow down like this. If using a source control system like ClearCase where you can reduce unnecessary LAN communication (e.g. using a snapshot view), consider doing this.
I also find that running the executable separately (from outside Visual Studio) and then using VS2005 to attach to the process can be much faster. This is predominantly the way I work, and I find it much less frustrating.
Another thing to consider is whether you are using a symbol server to access debug symbols for the Windows DLLs. If so, VS2005 can sometimes try to access the symbol server every time you debug. The way around this is to load the symbols once, and then uncheck the symbol server URL under Tools->Options->Debugging->Symbols. As long as the OS libraries haven't changed since you last downloaded the symbols, there's no reason to access the remote server every time.
It sounds like it could be loading symbols for various DLL's which you probably don't care about. You can disable these in Options.
If not, what do you see in the Output window?
Related
*On Windows 7, Visual Studio 2012 Professional, if it's relevant.
I've been stuck on this issue for several days now and scoured all remotely related stackoverflow answers I can find with no solutions working. The project developers seem to have no idea and I don't think it's related to their code but rather my setup.
I'm attempting to debug a C++ application written by someone else, same code runs without issues on several other computers but freezes on my computer when opening a windows file dialog (for opening or saving files.)
Per the debugger it'll freeze while trying to load symbols from libraries such as:
shdocvw.dll (most common)
networkexplorer.dll
ieframe.dll
dfscli.dll
wbemsvc.dll
FirewallAPI.dll
npmproxy.dll
and a number of others. I've let it sit over night and once if freezes it never seems to recover.
I've essentially tried all the possible configurations in Options->Debug->Symbols, including enabling and disabling the Microsoft Symbol Servers, explicitly giving it the location where these libraries should be located, project directories, loading all modules or only specified modules, clearing the cache, excluding the libraries that cause freezes (they still load+freeze,) etc
Note that deleting all breakpoints, a common solution to these types of problems, has no effect.
It will very randomly work perfectly but then restarting the program, while changing literally nothing, will make the problems come back. It's rather infuriating. The most reliable method I've found is to let it load all symbols from the Microsoft Symbol Servers for one to three runs, and then once that stops working clear the cache and run it completely locally one time, then go back to the Microsoft Symbol Servers. Though that's not a very good solution and odd that it works.
Any ideas for an actual solution?
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
Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.
If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.
For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.
But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.
MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.
If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.
If its Windows app, try enabling/disabling LargeAddressAware.
If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine
debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.
most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.
in other cases, supply us with snippet, so we can tell something more!
#Matt this cant be heap problem, it can happen but its extremely rare.
#Huytard its wont happen, without linked dll's program should't even start.
The correct and short answer. Run Windows Updates.
The correct and long answer.
It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).
But here's the kicker!
If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.
http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build
Running the green "play" button will use the IDE's environment
Executing from the directory will use the default environment
My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.
Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.
For example:
#echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe
I'm trying to speed up my debug iterations of a plugin. The host application is quite large and there are some hundred symbols from the OS and the main application. Only one .dll and one .pdb changes but it seems to have to reload every symbol from disk on demand. The launch times before I hit my breakpoint is almost five minutes. Running in release should be under one minute.
Things I've already tried:
Removing other unused .dll's : helped but unpredictable results
Edit and Continue: this worked "great" in the past. It doesn't work in this version of the host application. This might be due to some .net c++/cli wrapper for parts of the product (not related to the part I'm using)
Not using symbols: not a great debug experience for 60% of cases.
Leave program running, just unload my .dll: Unsupported since dependencies are unpredictable.
Any recommendations for speeding up my workflow?
Specs:
OS: Windows 7 64bit
IDE/Debugger: visual studio 2010 sp1
language: c++
crt version: sometimes v90, sometimes v100 depending on the version of the host app.
using ms symbol server: yes
edit and continue: broken
Application Startup time: 4-5mins
total count in modules window: 589!
Use a Ramdisk and store the frequently-accessed symbols on it.
Some other things you can try
Declare an environment variable called _NO_DEBUG_HEAP=1. Very useful for a large application that do lot of heap allocations
Avoid loading the MS symbols by default. You only need it once in a while in which case I just Right Mouse Button in the callstack window and pick Load symbols from -> Symbol Path or Microsoft Symbol server
See if you can upgrade to a SSD hard disk.
Working on a Win32 DLL using Visual Studio 2008 SP1 and, since yesterday, whenever I try to right click on code, to go to a variable definition for example, VS completely locks up and I have to manually kill the process. To make it even weirder, whenever this happens the devenv.exe process uses exactly 25% of the CPU. And I mean exactly, never 24%, never 26%, always 25%
Also, I've run ProcMon to see if devenv is actually doing something, but it's doing absolutely nothing external of the process. No disk, network, registry access. Nothing.
This is getting really aggravating because I have a large code base to deal with and the only other way of jumping to the definition is to first search for it.
Has anyone run into a similar issue? And, better yet, know a fix?
Edit: More info. Other projects (even an older version of the same one) work fine. I diffed the project file and the only differences is added source files and a /D define in the command line params.
Edit 2: So, it seems that now it's actually because intellisense is stuck updating. For some reason the status bar was disabled, but when getting it back I say "Updating Intellisense... (186)" and from what I've read, that 186 means that there are 186 background threads working. 186?! But, procmon still shows no IO whatsoever.
Try deleting all .sbr .bsc and .pdb files.
For the 25% CPU load: I guess it uses one core on your quad core machine.
If you have Visual Assist installed, try disabling it.
On connect, a submitted bug: Visual Studio Hang, seems to closely resemble your issue:
At random times, when I right click in the text editor, in this case C/C++ editor, Visual Studio will just hang. And if I wait it out, it still hangs.
It seems the workaround is to exit Visual Studio and delete the intellisense (.ncb) file in your project directory and reopen it.
The issue you are seeing is an intermittent failure in prior versions of Visual C++ that is hard to diagnose, and has a relatively simple workaround, as you have discussed, which is to delete your NCB. In order to get proper intellisense for header files, they would need to be included by a .cpp file in your project (directly, or indirectly through another header.)