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
Related
I just installed Neo4J community for windows10 . The menu can launch Neo4J and shows the small window with 'choose database' and 'stop' and 'start'.
Everything seems ok, i can start, use the db, and stop.
I can restart or stop, as long i don't close this small window.
If i do, i can no more start Neo4J as it is still running in background (seen in task manager ) and never show again this small window.
As a workaround, i kill the app in task manager, then the window re appears on next start .
any idea ?
Even though the window has gone away, the process itself is still running (neo4j-ce.exe). If you open the task manager, look under "Background Processes" and find it there. Select it and then press "End task". You can restart Neo4J after that. I haven't found an answer as to why you have to do this, but it seems to have popped up with the 3.1 version.
When the Neo4j database is stopped by clicking the stop button and the GUI closed by clicking the X in the corner, the Neo4j process continues to run in the background as described by chrisvest Neo4j process still in memory after stopping and closing the window. This is a feature. However, trying to launch the GUI again from the exe or a link to the exe will not work. You will have to locate the small Neo4j icon in the taskbar and click on it. The GUI will reappear. There is no need to kill the Neo4j.ce thread or restart the computer.
My application is causing the following strange behavior on Windows 8:
Conditions:
My native WinAPI application is started automatically upon Windows 8 startup.
Windows remains at the Start screen immediately upon startup.
When my application creates a window, Windows switches to desktop away from the Start screen. The window created is toolbar window, it does not steal the user focus, used as status display.
This only happens when the window is being created not immediately after the startup, but some seconds later.
My question: How can I prevent Windows switching to desktop when my window appears?
Well, you can manage start up applications. Turn it off for your application. And it should work.
I have a question about the expected behavior of Window Phone 7.5 emulator.
If I deactivate (start button), close (back button from first screen) or tombstone my data (selecting this option in VS first and then in the emulator clicking start button), and then press Stop Debugging (Shift+F5) in VS, all changed data in my app for that session is retained when I start the debug process again (F5).
However, when I just changed data in my app in the emulator and don't actively deactivate, close or tombstone my app, and then press Stop Debugging (Shift+F5) and then Start Debugging (F5) the changed data is not retained. I've noticed that upon stopping debugging, neither the Application_Deactivated or Application_Closing occur as well.
Is this expected behavior when starting/stopping the debugging processes? I'm asking because I need to know if this has any effect in the real world, like for example if I'm in my app and make a change and then someone turns off the phone completely right then and there and turns it back on, will my data be retained
This is expected. What you are doing is effectively crashing your app. If the phone/app is shut down in a normal situation then Deactivated or Closing will be invoked.
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.
I have an application that manages patient demographic information. Along with this data a user can scan a picture of a patient and assign that picture to a patient. When the user clicks the scan button a separate application is opened as a dialog in order to scan the image. When running this on XP everything worked fine. The imaging application loaded up fine and gained focus. On Vista however occasionally the imaging application will not gain focus and will popup behind the main application. When running full screen or through 2008 Application Server you cannot see the application, you only get a locked screen and it appears nothing has happened. Is there any way to change the window focus management on Vista to work the way XP did? I'm looking for a way to solve this without making changes to the actual application if possible.
I think you will have to make changes to your application to allow the imaging application to take the focus. I'm going to assume that your application launches the imaging application through ShellExecute or CreateProcess. If so, you can get the process handle of the launched process either through SHELLEXECUTEINFO.hProcess (for ShellExecute) or PROCESS_INFORMATION.hProcess (for CreateProcess). Immediately after launching the imaging application call the AllowSetForegroundWindow API:
AllowSetForegroundWindow(GetProcessId(hProcess));
This will allow the imaging application to place its main window/dialog in the foreground when it's starting up.
You could try the following steps:
1. Right Click on the exe
2. Select Properties
3. Select the Compatibility Tab
4. Check the Run this program in campatibility mode for:
5. Select Windows XP (Service Pack 2)
You could iterate through all top level HWNDs and identify the scanning application via its window class, then send an appropriate message to raise the window.
I don't believe this is Vista vs XP related. I think that simply this imaging app takes longer to start on Vista.
Since Windows 2000, the window manager has prevented background applications stealing the foreground. When an application is launched, it has a window of opportunity to create and show a window that will take the foreground. If it takes too long, the window manager thinks that the current window should keep the foreground, and inhibits the other app taking the foreground when it does finally launch.
I can't think of any specific way to avoid this... other than using FindWindow to search for the other apps window after launching the app. When you eventually find it, call SetForegroundWindow on it to bring it to the foreground.