I'm writing and then debugging a console application in VC++ 2008, it then happens that closing Visual Studio IDE, the console window remain opened, and there is no way to close it!
Also if I try a machine reboot the machine doesn't restart. The only way is turning off the power.
In the process list there are no signs of the console window.
If I try to investigate the console window with tools like Spy++ I found the window but in the "process" tab there is a process ID that doesn't exists, in the "General" tab the "window proc" field says "Unavailable".
How is it possible?
How can I kill those type of windows as there is no processe to kill?
thanks
Most annoying bug ever; get the hotfix.
Related
If I close a browser running a web application, it is desirable that the debugging session dies. After all, this equals to closing a windows application. However, if I stop debugging and the browser has more than one tabs (as often is the case), all of them will close - definitely not what I intended. Not using this option means I continuously forget the debugger running and clicking the stop button is just extra work.
Is there an add-on to Visual Studio or any other trick that allows to do only the first: stop debugger when window is closed?
Who thought it would be a good idea to put two options behind a single checkbox? This is a double-edged sword at its sharpest!
It's not exactly what you want. But, it might be a workaround. If you enable JavaScript debugging in Tools->Options->Debugging and then you Debug->Detach All. The browser should stay open and debugging should stop... Now it would mean that the application is still running, which might not be desirable.
It's a great suggestion to make this an option. I'd encourage you to open a suggestion on developer community.
Tools Options:
Detach:
I re-compiled the Tor Browser on Windows with minGW, and after I launch Tor, the console window opens too- he shows me all the details from the begging of launching Tor.
There is a way to hide this console window?
by the way i did the same thing in Linux with Terminal and it did not open the console window.
The way that you can hide the console window is to add to your "main" file this line
ShowWindow(GetConsoleWindow(), SW_HIDE);
and re-compile again.
it will open your tor.exe console window for less then 1 second, and will close him self automatically.
if any one else knows how to completely avoid the opening of the console window ill be glad to hear the way to do that.
When my program is paused in Visual Studios 2010 during debugging, like from reaching a break point and me doing a manual step through, the program window becomes impossible to view.
It is a GUI window not a console window, which I run simultaneously with my program and am still able to view. The window seems to be open it's just that when I click its icon on the taskbar it doesn't come to the front of all the other windows. When I minimize all the windows in front of it, I see the outline of the window but it is either blacked out or showing the remnants of previously expanded windows.
I've noticed this with using Visual Studio's before (various versions of it), and after trying other IDE's that didn't have this behavior I notice it more. It would be really helpful to view the program's change's as I step through the program. Anyone know how I can do this?
I searched a long while and couldn't find a single reference to this matter.
The reason the window doesn't display is that the window paint message won't be processed if the main thread has been paused. Which other IDEs let you do this? I haven't come across any native code debuggers that do this on Windows.
If you are stepping through code that is run by the main thread, then the main thread can't simultaniously poll the message pump, which is needed for the GUI to work.
If you debug a different thread, the GUI will work while you are debugging.
I'm trying to debug a VS 2008 command-line application running under Windows XP. The application has been crashing (access violation), and I am catching the crsah in the debuuger. After looking at the call stack, etc., I tell the IDE to "Stop Debugging". The application window remains, but the process does not appear in Task Manager. Nothing happens when I click the "X" in the upper-right corner, though I can minimze / restore the window. The process is normally shut down by pressing Esc. It does not respond to this keypress.
I cannot even get rid of the application window by attempting to reboot XP. The machine will not reboot; it simply ignores my command to do so.
The only way I've been able to get rid of the application window is to do a hard power cycle. Ughh...
Does anybody have any suggestions on how to clean up this lingering application window after the application crashes?
Thanks,
Dave
My app installs the visual Studio C++ runtimes on a remote machine as a prerequisite for another installation. On Windows 2003 when I upgrade to the latest patch of the VS 2005 C++ runtimes the upgrade appears to stall after the embedded MSI package has been run. The fix was to use the /Q:A rather than the /Q argument to the vcredist.exe bootstrapper.
Running the same command from a command prompt doesn't cause the modal dialog box to appear, so it's appear impossible to inspect the dialog box and reassure myself that I'm not just masking another problem.
Anyone got any tips for viewing dialog boxes in other window stations or sessions (currently the dialog is in session 0).
I think you cannot really view the dialog box. However, you can either try to attach and debug the application when it is frozen or attach and generate a dump of the application.
You must run your debugger as an administrator to attach to the process in session 0. In your case, I think you should look for msiexec.exe processes running in session 0.
You should be able to find the thread displaying the dialog box.
To inspect the contents of the dialog box, may be Spy++ will do the trick (not sure it is able to find windows in another session)