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.
Related
I have a C++ gradle app set up in Visual Studio 2019 Community Edition targeting Android. I'm using NDK 20 (the latest version in Microsoft's android sdk repo).
This app is composed of several .so libraries (SDL2, SDL2_image, SDL2_ttf, WolfSSL, MyGameCode, MyGameLibrary, MiscellaneousExternalDependencies.a) and all seems to compile and run properly. The issue I have is in attaching a breakpoint and seeing GDB trying to load the symbols for the associated .so (in this case, my game code specifically).
I have done some testing and found that if I strip out all my game code I can get breakpoints to hit with just my library and all other dependencies. I've also tested and found that including most of my game files still runs. However I have about 10 files that if I remove them everything seems to load just fine. It takes about 42 seconds to load symbols when I have a stripped down version of my project which allows for breakpoints to be hit.
It seems to be total symbols in the project rather than any specific code running during the application's lifetime since I have a main finction in C++ specified which does not load any of my game code and just runs a simple SDL2 test and simply by changing the number of files included in the project I can reproduce the GDB crash or eliminate it.
I should note that my project seems to run just fine without the debugger attached, and I can see output from the C++ modules I'm trying to set breakpoints in. The issue I have is limited to when I try to connect GDB and access a breakpoint through Visual Studio. At that point I am getting what appears to be a stack overflow (or possibly a timeout?) during the symbol loading process.
My question here has a few bullet points:
does GDB have some kind of symbol limit?
If so, is there a way to strip unused symbols from the final ".so" during the build process from within Visual Studio? I want to keep my build process simple to execute.
If not, can I break my project up in some kind of way with .so or .a files to get around this? It doesn't seem that it makes a difference currently if I do that so more advice would be appreciated!
Does Visual Studio's wrapper of GDB and the Android Emulator allow me to increase the timeout if there is a timeout? If I could specify it at like 200 seconds that would definitely be more than enough time to load my project's .so symbols.
Are there any other possible explanations for crashing on loading symbols in this way that have plausible work-arounds?
Essentially I don't know why it's crashing during loading symbols for my .so file
I have provided additional details here including a link to my project and exact testing methodology, but the full thrust of this question is present in this post.
https://developercommunity.visualstudio.com/content/problem/898890/gdb-exited-unexpectedly-with-exit-code-1073741571.html
It turns out replacing the gdb.exe and gdb-orig.exe files from my Microsoft Hosted NDK version 20.0.5594570 with the ones I got from downloading NDK 21 available here solved the problem (r21 at the time of writing): https://developer.android.com/ndk/downloads
There must be a defect which has been recently resolved in GDB itself and which had issues with my project size and/or composition. The NDK r21 bundled version of GDB works perfectly, however.
I am trying to simply deploy an OpenGL, C++ application from one computer to another. The app was written using Visual Studio 2017 Community. The first computer has VS installed, the second does not.
The computers have Intel Core i7-8550U CPU and Intel Atom x5-Z8350 CPU, respectively. Both are running Windows 10 Home.
The VS project started as an empty project to which I added everything.
I have copied the release, x64 application .exe file and the one .dll file necessary to the project development to a single directory on the second computer.
Microsoft instructions for local deployment say “Local deployment, in which you copy particular Visual C++ DLLs from your Visual Studio installation—typically in \Program Files (x86)\Microsoft Visual Studio version\VC\Redist\platform\library\—and install them on target computers in the same folder as the application executable. You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share.”
Nothing I can see or find to set in VS tells me what .dll files are being used by the application I developed and run on the first computer. There is a VS output window that shows a number of .dll files, but those are in c:\windows\system32.
From the reference in the Microsoft instructions regarding the MSVC DLLs in \Program Files (x86)\Microsoft Visual Studio version\VC\Redist\platform\library\, I looked in ..\VC\Redist\MSVC\14.16.27012\x64 on the first computer and found these folders:
I have copied the DLLs from the .CRT directory and the .MFC directory to the second computer to no avail.
When I try to run the application on the second computer it displays the message “Failed to create GLFW window”, which is in the code I wrote as shown here:
It would seem that there must be a straightforward way to do this. I have seen reference to an old Microsoft application (I think), depends.exe, which provides the a list of the DLLs required, but it is no longer deployed with Windows systems.
missing DLL or RTL
causes crash or even no error but just instant closing your app (that is what missing or miss-matching MSVCPP RTL is doing or was at some point).
As the RTL libs are changing all the time (IIRC once in a year) there are a lot of versions already so good luck using MSVCPP apps on fresh OS computers. In order to use some app you usually need to find out which version of RTL it needs which they usually do not report so you will end up with installing all of them you get hands on ...
There is a way around this problem just enable your compiler/linker to link all the stuff it needs directly into exe file instead of using RTL DLLs. However I do not code in MSVCPP and from what I heard MS removed this option from their environment (other compilers I use still have it)
Your error message indicates your App run as should and is not missing anything.
The problem is on GL side. Windows 10 is usually forcing wrong drivers (and not just for gfx cards). The goto case is enforcing (most likely intentionaly) buggy MS drivers (where GL is bugged and DX more or less works) instead of vendor provided. To remedy this (check the driver manufactor and if not what it should be) download&install correct driver from your gfx Vendor site Do not use Windows Driver service for gfx cards !!!
You can use DUMPBIN /DEPENDENTS EXENAME to get a list of bound DLLs. Mind you this only lists DLLs with import table entries, if you're instantiating COM objects this won't help at all.
My guess is you're probably missing the opengl driver/dll on the target system.
ed: actually I'm going to narrow that down to missing the driver, since if you were missing the DLL you'd have gotten an an error on load. The fact you're able to call the function means you bound to it, but that you're only getting failures when it tries to call the driver. Try calling something benign that queries for driver or device info, like a version or string. If that fails you know the driver is missing.
*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?
I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires SeDebugPrivilege to be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to use OpenProcess()/ReadProcessMemory()/WriteProcessMemory() and doesn't handle errors correctly, it's conceivable that it could crash.
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx
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?