The application I'm working does not start in the debugger of Visual Studio 2005.
Here's what I do:
I rebuild the application and hit F5 to start it
The title of the VS2005-window says "projectname (Running) ..."
The debugger buttons appear but are greyed out
The application appears in the Windows task manager, but it has only 80k in memory usage
Nothing happens for a long while, and finally I get a windows with the following error message: "Debugging is being stopped but is not yet complete. You can force debugging to stop immediately, but any process being detached may be terminated instead. This window will automatically close when the debugging has completely stopped". The window does not disappear, so after a while I press the "Stop now" button.
Nothing happens for a while (the debugger buttons still visible, but greyed)
Some time later a new window appears: "Unable to start program '(path to exe)'. OLE har skickat en begäran och väntar på svar". The last sentence is swedish for "OLE has sent a request and is waiting for response". I press OK and the debugger buttons are gone.
The application is still running, and still has only 80k in memory usage.
I try to end the process with the task manager, but it is not killed.
I quit Visual Studio and finally the process is gone.
The application is an unmanaged C++ project, that use a lot of DLL-files as plugins. I'm using the "multi-threaded debug" runtime, and I've made sure all dependencies are compiled against the same runtime.
It was while doing that this problem appeared all of a sudden. I've tried to reverse my changes, but it doesn't help. Restarting the computer doesn't help either.
I've got the application running once or twice at random. If I then ended the application and started it again it wasn't started. So I don't think this is because of my configuration.
Any ideas?
One more note: the application starts and runs as it should if I start it from outside Visual Studio.
Sounds like a misbehaving DllMain() in one of the implicitly linked DLLs used by your program. You might get a hint from the Output window, it lists the names of the DLLs as they get loaded. If it is wininet.dll then you've fallen into a deadlock trap with the symbol server.
Ok, I've solved my problem, but I have no idea how.
One thing i tried was deleting all build files and exe and dll files, and then recompile everything. But that didn't help.
I then tried one thing at random: the plugins were in the same solution. So I removed them and tried to run again. And this time it worked! So I added all the plugin-projects back, and it still works!
So, I guess I will never know what happened. But removing and adding a project to a solution might solve someone elses problem too ... :)
Related
I have configured my windows 7 to create mini dump files on crashes but when my application crashed, no dump file was created. The search for answer left me rather confused as to when are dump files created, when windows crashes or my application crashes?
In my case, I am looking for dump file when my application crashes. I receive a typical crash dialog that states:
TheApp Application has stopped working
Windows can check online for a solution to the problem
-> Check online for a solution and close the program
-> Close the program
-> Debug the program
So can I generate dump file for my application when it crashes? I can't produce this bug on development machine so I want to walk back from dump file. Is there any other option to trace the source of bug (to source code)?
First of all, there are different places to configure a "create a minidump on crash" setting, which are totally different.
You can configure Windows to create a kernel dump file when Windows crashes, i.e. when a Bluescreen of death (BSOD) occurs. This is done in the following screen on Windows 7:
You can configure Windows to create a user mode dump file when an application crashes, i.e. instead of the "Windows Error Reporting" dialog which would normally appear. To do so, and you know that in advance, then configure a Registry key called LocalDumps (MSDN). By default, dumps will be created below %LOCALAPPDATA%\CrashDumps and they will have the naming scheme app.exe.<PID>.dmp.
For the sake of completeness, there might be other triggers. The only sure way to tell is: when the method MiniDumpWriteDump (MSDN) is called.
I'm quite sure that you want option 2 of the above. If you have trouble with it, see whether all the conditions for LocalDump are fulfilled.
The answer given by #antlersoft does not work, for the reasons I have posted in my blog: at the time the dialog is shown, Windows has triggered a breakpoint to stop the application and it has injected a callstack of Windows Error Reporting. All in all, not a good starting point for debugging.
What would work is:
attach a debugger of your choice
press "Go" in the debugger
press the "Debug" button of the WER dialog
confirm the warning about the debugger which is already attached
click "No" when asked to start debugging using the selected debugger
Using Task Manager to create a crash dump is not recommended, since it will not consider the bitness of the application, which may cause trouble later. See ways to create good and useful crash dumps.
Minidump is created when Windows crashes. It's not intended to application crash.
If you want to debug crashes of your application, you may attach it to a debugger after it is started. Clicking on the "Debug" button when application crashes do the same. You can use the debugger of MS Visual Studio to do that, for example.
See this page for help on attaching a process to MS Visual Studio debugger:
https://msdn.microsoft.com/en-us/library/3s68z0b3.aspx
EDIT: following text removed, as this may not work as expected (comment from Thomas)
You can also create a dump file from task manager, however you will still need a debugger to analyze it and, actually I am not sure you will be able to get the dump file at the point application crashes. The best way, if you can, is to debug the process on the target machine by attaching it to debugger either after it is started or when crash occurs.
When you get the crash dialog, go to Task Manager, find the process, right click on the process, and select "Create dump file". The dump file is created in the AppData/Local/Temp folder for the user; it will be named %AppData%\Local\Temp\.DMP; if you create multiple it will be -1.DMP, etc. You can move the dump file to your development machine and open it within Visual Studio. Visual Studio will then act as if you had hit "Break all" at the point of the crash while running the process in the debugger.
I have a strange problem using Visual Studio 2010.
I'm running a DLL, which is loaded from IIS in the process w3p.exe from Microsoft. When I start the remote debugger on another machine and attach my local machin there, everything is fine and I can debug.
The problem is when I run it locally. I know that the DLL is loaded (because of logfiles) and I can attach the debugger to the process. But when I try to Break all I get an error saying
Unable to break execution. This process is not currently executing the type of code you selected to debug.
The project settings are definitely pointing to the project that just compiled the running DLL, so I don't really understand this error message.
Also when I set breakpoints nothing happens. The debugger is attached though, because when I stop IIS then I get an error message telling me that the debugger needs to be stopped first.
I'm using an intentional application error fopen(NULL, NULL) which will allow me to attach a debugger in the debug build. But this is rather annyoing, because I have to clear the call stack manually before I can actually start debugging. Using __debugbreak() doesn't help, so I have to use this clumsy workaround.
So can anybody tell me why this works remotely, but not locally?
So I finally found a solution to my problem.
When opening the attach dialog there is an option Attach to: Managed... with a Select button beside it. By default this was set to Managed (v4.0). Now I added Native code and this solved my problem. I can attach now locally as well.
I sure don't understand why this works on a remote machine, because the code is exactly the same though, so there shouldn't be such a difference.
I'm using a 3rd party dll with no source code available. It runs perfectly fine, but every time I run my program, an annoying pop-up says "MyProgram.exe has triggered a breakpoint".
If I press continue, my program runs 100% correctly.
If I press break, I can see that the breakpoint is occurring in the 3rd party file alp41basic.dll
I have no clue why they put breakpoints in their dll. How can I disable them?
My question is identical to one that went unanswered:
https://stackoverflow.com/questions/17514072/is-there-a-way-to-make-visual-studio-continue-when-an-exception-occurs-on-a-line
I eventually checked in with the company that distributed the dll, and indeed there are breakpoints in there for reasons that I won't get into. However, if I run the program outside the debugger (even simply open the binary from windows), these popup windows do not occur.
Thank you all for your help!
I finished migrating an application from Qt4 to Qt5, it compiles and runs but as soon as the main window is opened I cant do anything (interact with items, or click or anything). its just not responding. I tried debugging it but in the main.cpp reaches the return a.exec(); statement and trying to debug further than that is not posible, the yellow arrow wont go anywhere past that, and if I insist too much it eventually disappears. The functionality of the program is supposed to be alright, I only migrated it.
What can be causing of this problem? I would post some code but there are so many .cpps and I have so little clue about the issue that I dont know what to post.
I know its not much information, but if anyone has had this problem or knows something related to these symptoms please just say it, it will be better than nothing.
If I missed anything please tell me
Thankyou.
Some more info
Platform: Windows 7 x64
Compiler: MinGW 4.8 32bits
Application: 32bits
I did compile all the libraries and the app in debug mode (except some such as Qxt, which is compiled with the command line and zlib and Qt5SerialPort which includes the debug version itself)
Try disabling all child widgets in your main window and then turn them on one at a time till you find which one is causing the blocking.
I left a program running last night, it worked fine for about 5 hours and then one of its built-in self-diagnostic tests detected a problem and brought up a dialog box telling me the issue. The program was built with debug information (/Zi). Is it possible to somehow get the debugger started so I can examine the value of some variables within the program? Or is it too late?
You can attach the debugger to the running process:
Debug > Attach to Process...
Just open up the program's solution first.
Assuming you've still got the error dialog on the screen you can break into the program and work back up the call stack examining variables etc.
For the future crashes ... if you have windbg or Visual Studio Professional, you can debug crash dumps, even when program isn't running. It is quite useful sometimes. See "MiniDumpWriteDump" on MSDN for more info.
Other than that it is "Attach to process".
Professional edition of Visual Studio have Just-in-Time debugger, that will kick in as soon as anything crashes, even if MSVC wasn't running. It will also locate source code (if debug info and source code are available) and open/create solution for you.
There is an option in the Debug menu to attach the debugger to a running process, IIRC.