I have a fairly standard C++/QT app that works fine in debug and release on my development PC. When trying out the release version on a clean PC it runs but part of the functionality (showing video via a USB connection) just doesn't run. Well, seen this before and my standard technique is to add debug information to the release build, setup remote debugging and have a look. Much to my surprise, it runs fine as a release build with debug info (.pdb)
I have never seen this before.
using dependency walker shows no problems with any dependencies. Using the profiler that is a part of Dependency Walker and it also runs perfectly.
I have run out of debugging techniques and the only thing I can think of is to add message boxes at various places which in a multi threaded application does not seem a good idea.
Is there a debugging technique that could help me find this problem? We're using VS2008 and Qt 4.7.1.
Refine your message boxes - use a log file.
From your description, it seems to me that there may be some sort of race condition/timing issue that gets solved when some thread or other gets slowed down by being observed by something. Or by adding debug info to the binary.
Using a log file with timestamps, you should be able to keep track of when things happen.
I think logging is your friend. If you have multiple threads you may want to log each thread to different log file.
Related
Creating a ATL COM DLL in Vs2015 for a VB6 consumer is going badly because the "fault tolerant heap shim" is being applied to VB6, which I am running from the vs2015 debug command.
I have found many posts about disabling FTH in Windows 7, and indeed I have applied them all, including deleting the DLL in \Windows\AppPatch, as well as disabing FTH in the registry AND running the rundll script that is cited.
Still, this damn thing is making it impossible for me to debug the dll, because the FTH makes it run like a dog under VB6 in debug mode.
I even added "vb6.exe" and "full_path_to_vb6.exe" in the exclusions list in the registry -- to no avail.
I desperation, and needing to get some work done today, I have renamed vb6.exe to myvb7.exe (!) and this gets rid of the FTH alert in the VS debugger. But why can't I disable FTH for vb6.exe?
In fact, why does it even get enabled at all when a debugger is attached? It's driven me mad today.
Anyone?
There wasn't too much help forthcoming on this. For future reference, if the application (in this case VB6) is set to run in compatibility mode (either from a right click on the shortcut you use to launch it, or from a property set on the target exe itself) then nothing you do will release the shim!
Solution: don't run vb6 in compatibility mode under Windows 10!
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 debug a C++ app on Windows XP and when I start debug mode, after all the initialization is done, the main window won't show. It works, however, on W7.
So I checked the msi installer I have available for the app and after installing the app, the problem seemed to disappear. I uninstalled the app and it still worked.
I need to know which registry entries and DLLs the installer modified so I can identify the problem. Is there any way to do this?
Yes. Microsoft's Process Monitor is free and tracks every file I/O and registry read/write a program makes, including an installer. However, there will likely be many such changes.
Because procmon works by monitoring processes as they run, you'll have to run the installer again.
Problem solved. The issue was that the app would try to acquire a lock on null objects, fail at it, and then release the lock. So when a next acquire would be made, the app would crash. It's strange that the same code works just fine on Windows 7, but my guess is that there some improvements in the Win API, in the lock sections.
Process Monitor would've been useful, but the installer had waaay too many threads and registry changes to be able to follow. The snapshot would've been as complicated as Process Monitor and diagnostic logging.
Thank you for your help, guys :)
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?