I'm debugging plugins on Windows 7 and of course the plugin host (Cubase5.exe) occasionally crashes because of errors in the plugin. On XP or Vista, I could always restart it immediately and continue working. But on Windows 7, even though Cubase appears to close, it is still visible in Task Manager and I cannot kill it by any means. After a minute or two, it disappears by itself. In the mean time, I can't work because the plugin DLL is still locked by the process.
Does anyone know why this happens on Windows 7? I've already tried disabling Automatic Error Reporting but that didn't help. I've tried attaching cdb to Cubase, but I get:
Cannot debug pid 5252, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
Debuggee initialization failed, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
I tried following the instructions here but it appears this is only possible if I connect a second machine to my computer to debug it remotely.
I finally found the solution, using this article:
http://blogs.technet.com/b/markrussinovich/archive/2005/08/17/unkillable-processes.aspx
This required installing the Windows Debugging Tools for Windows (nice name) and LiveKd, but by following the steps outlined I was able to track which driver was causing the process to hang: it turned out to be the 64-bit driver for the M-Audio Oxygen 8 V2 controller I'm using. Unfortunately no driver update is available.
Anyway, if anyone encounters a similar problem, this is the way to solve it.
Have you tried Process Explorer by Mark Russinovich? It is really useful for "killing":)
If you have error reporting enabled, it's possible that werfault.exe has Cubase open to write a minidump for crash reporting purposes.
This is just a stab in the dark but it might be your problem.
One thing you can try is to check with Process Monitor what Cubase is doing. Set a filter so that everything with a process name containing "cubase" will be recorded. It could be that you are facing some timeout issue when Cubase wants to exit.
you can end the process the service is running under. You can find this process by going to the Services tab of the Task Manager, right-clicking, and selecting Go To Process(you need to click the Show processes from all users button.). Note that one process may host multiple services (especially if it's svchost.exe), and ending the process will kill all those services. Also, this is an unclean exit, and may cause data corruption depending on what the service(s) was doing when you killed it.
Depending on which specific service you are trying to stop, there may be a cleaner way to simulate failure.
Related
Yesterday I ran a BIOS update on a Windows7 computer. The BIOS update tool performed a shutdown of Windows and without restarting the computer (so directly after Windows shutdown), a DOS-like tool started that updated the BIOS.
I searched the WWW but all I can find is how to execute applications at Windows shutdown (so before windows goes down) or at logoff (logoff scripts).
Does anyone have any clue on how to achieve this?
It is my guess that the machine had in fact performed a soft-reboot and was running BIOS code. That's the usual approach, and in some cases the soft-reboot may not be visible to the user, i.e., the BIOS self-update code may run before the POST.
However, it is (or at least used to be) possible to run Windows code post-shutdown, although obviously it is limited in what it can do. The key information can be found in the MSDN library entry on the Service Control Handler Function:
After this time expires, system shutdown proceeds regardless of whether service shutdown is complete. Note that if the system is left in the shutdown state (not restarted or powered down), the service continues to run.
So, at least in principle, all you need to do is to install a service that asks for shutdown notification but does not actually stop when shutdown occurs, and then instruct Windows to shut down without rebooting or powering off. I have actually seen this happen, but only on older versions of Windows (before automatically powering off at shutdown became the default!) so I can't guarantee that it still works, although it definitely did once.
It should, however, be noted that this will not necessarily give you the sort of environment you may be thinking of. For example, device drivers are not necessarily unloaded before shutdown; after all, what would be the point?
You can run Local Group policy - gpedit.msc (From run).
Under Computer Configuration choose Windows Settings
choose Scripts(Startup/Shutdown)
On Shutdown properties you can add script and also mention parameters if needed.
I also advised you to look at the following question - how to delay shutdown and run a process in window service
I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?
How to reload a crashed process on Windows? Of course, I can run a custom monitoring Win service process. But, for example, Firefox: it doesn't seem to install such a thing, but still it can restart itself when it crashes.
On Vista and above, you can use the RegisterApplicationRestart API to automatically restart when it crashes or hangs.
Before Vista, you need to have a top level exception filter which will do the restart, but be aware that running code inside of a compromised process isn't entirely secure or reliable.
Firefox constantly saves its state to the hard disk, every time you open a tab or click a link, or perform some other action. It also saves a flag saying it shut down safely.
On startup, it reads this all back, and is able to "restore" based on that info.
Structured exception handling (SEH) allows you to catch program crashes and to do something when it happens.
See: __try and __except
SEH can be very dangerous though and could lead to your program hanging instead. Please see this article for more information.
If you write your program as an NT service then you can set the first, second and subsequent failure actions to "Restart the service".
For Windows 2008 server and Windows Vista and Windows 7 you can use the Win32 API RegisterApplicationRestart
Please see my answer here for more information about dealing with different types of program crashes.
If I recall correctly Windows implements at least some subset of POSIX and so "must" have the signal interface (things like SIGKILL, SIGSEGV, SIGQUIT etc.).
I've never done this but on linux, but you could try setting the unexpected termination trap with signal() (signal.h).
From quick scan of docs it seems that very few things can be done while handling signal, it may be possible that even starting a new process is on forbidden list.
Now that I've thought about it, I'd probably go with master/worker pattern, very simple parent thread that does nothing but spawns the worker (that does all the UI / other things). If it does not set a specific "I'm gonna die now" bit but still dies (parent process always gets message / notification that spawned process died) then master respawns the worker. The main theme is keep master very simple and hard to die due to own bugs.
An application is hanging occasionally, and I would like to see the dump at the time to figure it out. I had written an application that the user can run to automatically create a dump that I can look at. However I can't seem to get the users to remember to run it when it hangs, no matter what I try. They always end up closing the program, which invokes Windows Error Reporting.
WER will create dumps in the temp directory, but unfortunately they are deleted as soon as the dialog for sending the info to Microsoft or not is closed.
Becoming an ISV and getting this info from Microsoft's error reporting servers is one solution.. but not one that is realistic at the moment.
I can't imagine that I am the only one faced with this issue. The software is used concurrently by dozens upon dozens of staff, so reaching them all and getting them to run an application or not click close on that dialog until running some other application or etc has not been working out.
The app is running on Windows Server 2003. Too bad, since I know Server 2008 has some LocalDumps options that will let me retain them.
Any ideas for somehow keeping these dumps around so I can analyze them? The obstacle is the user, in the sense that I've accepted to their stubbornness and do not expect them to run any other application or do anything special.
Thanks for any advice!
You could opt for an automatic solution. I believe there're multiple options at your disposal for detecting if you're hung.
One would be the use of SendMessageTimeout (also pay attention to SMTO_ABORTIFHUNG as one of the fuFlags values) from a separate thread in your app. Once you have determined the main thread is not responding you can save a dump file wherever you want.
There's also a IsHungAppWindow() (user32.dll) available since w2k.
Has anyone had and solved a problem where programs would terminate without any indication of why? I encounter this problem about every 6 months and I can get it to stop by having me (the administrator) log-in then out of the machine. After this things are back to normal for the next 6 months. I've seen this on Windows XP and Windows 2000 machines.
I've looked in the Event Viewer and monitored API calls and I cannot see anything out of the ordinary.
UPDATE: On the Windows 2000 machine, Visual Basic 6 would terminate when loading a project. On the Windows XP machine, IIS stopped working until I logged in then out.
UPDATE: Restarting the machine doesn't work.
Perhaps it's not solved by you logging in, but by the user logging out. It could be a memory leak and logging out closes the process, causing windows to reclaim the memory. I assume programs indicated multiple applications, so it could be a shared dll that's causing the problem. Is there any kind of similarities in the programs? .Net, VB6, Office, and so on, or is it everything on the computer? You may be able to narrow it down to shared libraries.
During the 6 month "no error" time frame, is the system always on and logged in? If that's the case, you may suggest the user periodically reboot, perhaps once a week, in order to reclaim leaked memory, or memory claimed by hanging programs that didn't close properly.
You need to take this issue to the software developer.
The more details you provide the more likely it will be that you will get an answer: explain what exact program was 'terminating'. A termination is usually caused by an internal unhandled error, and not all programs check for them, and log them before quitting. However I think you can install Dr Watson, and it will give you at least a stack trace when a crash happens.