We are writing a program that uses CefSharp to get data from some javascript heavy webpages.
After operating for a while, usually after we are finished but sometimes before, a message is logged to the console saying Destroying nonempty message queue and the program freezes.
I am at a loss as I can't even pause the debugger when the message appears, VS crashes with a debugger timeout when trying.
What causes the message queue to be deleted?
At the moment we did not solve the problem, instead we have figured out a way to tell when the process has crashed (basically we wait for three minutes and if we don't have a reply from the browser we assume it crashed), when the process is stopped we return a partial result to the user and it is the user's responsibility to ask for the rest of the data.
Regarding the crash itself, it isn't clear why exactly but it seems like we are doing something to crash the render process, and because we don't ask for anything over the WCF channel we have no idea that something has crashed.
Related
I'm writing a C# program that is supposed to serve as an intermediate step inside a PDFCreator workflow, while a document is being printed.
It's a regular console program and it works fine when everything else is fine. The root problem, as I've discovered, is that there is currently (i.e. in PDFCreator v4.1.3) no way to cancel the print job from inside my program, should the need arise. PDFCreator simply doesn't check the exit code and continues onto the next step regardless of what happened in my program.
Having exhausted the obvious options I've naturally resorted to the only way I could think of: killing the parent process from inside my app. This works, sort of. It cancels the immediate printing process.
But the problem starts again when I try to print another document. As it turns out, PDFCreator remembers the pending printing task as soon as the workflow starts. If it is killed before finishing, it stays in its queue and is retried the next time. This means the the tasks accumulate when I kill them!
I haven't had any success trying to determine where exactly the PDFCreator stores these pending tasks, so I can't delete them. And so I'm stuck.
I've raised the issue on the PDFCreator forum, but the community there seems to be rather slow to respond.
Is there a way to gracefully end a process without using Process.CloseMainWindow()?
I have a bunch of processes in a list which I want to end. The process should be ended without Process.Kill() to make sure they clean up and end their child processes as well.
I tried CloseMainWindow, but unfortunately it will make my process pop up a messagebox with "Do you really want to end the programm?"[Yes][No] which I want to avoid.
The processes have a message handler for WM_QUERYENDSESSION but when I tried to send a WM_QUERYENDSESSION message to the process, it didn't react on it. It just reacts on WM_QUIT, but the behaviour looks like the one when calling Process.Kill().
I couldn't find a proper solution yet. Hopefully I didn't overlooked things in here...
Sending the WM_CLOSE message is pretty much the same as clicking the close button on a window. Applications will be able to block this request or put up a "Save your changes" confirmation dialog.
Anything beyond this and you risk loosing data. WM_QUIT is not something you should be sending.
WM_QUERYENDSESSION is a query, you would send that first and then WM_ENDSESSION but not all applications will handle these messages.
Win32 does not have a main-window property, it is a .NET concept.
Another thing you should look into is the restart manager feature if you plan on restarting these applications again when you are done with whatever you are doing.
Well after a while I admit that there seems to be no real answer to this explicit problem.
Since I got control of both parts I just removed the "Do you really want to quit?" pop up like IInspectable assumed and send a message via the opened pipe to the child process like Sefe assumed.
I've been writing this program for a while now, and I'm finally ready to start testing it. It works 100% on my dev machine, but I wanted to try it on a machine it's never run on. So, I get my program over to a test computer. When I double-click the exe, nothing happened. I opened up task manager, and tried again. I saw the process start, but after about 5 seconds, it disappeared. No errors, no exceptions, no nothing. How would I go about trying to figure out what is going wrong? I'm still fairly new, and I've never had this happen. Thanks for any and all help!
EDIT
Sorry for not mentioning before. This is a winforms application.
EDIT 2
So, turned out what was going on is that I was trying to a dll meant for 64-bit OS into a 32-bit OS. In Windows XP, this threw a BadImageFormatException. However, in Windows 7, as I stated, it threw no exception at all.
This is a pickle, no doubt about it. I've had to debug this type of thing before.
The first bit of useful information is that no exception is being thrown out. This tells me that somewhere in your actual code is the key to solving the problem. You are either trapping an exception and closing silently, or your code is hitting what it considers to be a "normal" exit condition and is closing in what it would consider the normal way.
To figure out where and why it's exiting, I would add debug logging at key points in your application, and attach a listener to the Debug/Trace listener collection that writes out to a file. "Key points" are places where the application is supposed to exit (or the main form of the window is supposed to close), and within any "catch" block or error event handler. Run this new version on the test computer and see what it gives you. That should tell you the basic flow of the program behind the scenes, and through what mechanism it's shutting down.
If you're running a console application, it is possible that it runs and then closes itself.
Trying opening a command prompt, and then executing the application from there.
If your program has output, then you would see it in that command window.
Have you checked the application event log?
Do you have the necessary version(s) of .Net installed?
Perhaps you should put more exception handling with calls to MessageBox.Show("I failed here") through out your application.
I have the following scenario:
My app gets some data from the command line.
After getting executed by the first time, my app runs always one instance and that instance will be in memory until the use explicitly tells it to shutdown instead of just hiding the form when not needed.
When the user tries to run the app a second time, the process starts, checks if there is another one in memory and if that is true, it sends a WM_COPYDATA message to the process in memory with the data it got from the command line and exits.
That all works well when the it«s the user who runs the app.
I needed to ran it from the Microsoft Word 2003 toolbar so i used a "Add-in" for that. The problem is that when my app is started from that Add-In (using Process class), it seems that the process already in memory gets a WM_ACTIVATEAPP message instead of a WM_COPYDATA one, so i can't get the needed data sent from the process started by the Add-In.
I have no idea on why is that happening and how to fix it. I've googled for hours and nothing helped...
Can anyone help?
Getting a WM_ACTIVATEAPP message is quite normal, part of the usual notifications that Windows sends. Don't assume that the first message you'll get is WM_COPYDATA, keep looking. If you don't get it at all then the window handle that you used to send the message was wrong. Which is a very common problem, it is not that easy to accurately find a window back.
The .NET framework already has very good support for single-instance apps that can retrieve the command line from a second instance. Consider using it instead. Check this blog post.
We run a C# console application that starts multiple threads to do work. The main function looks something like this:
try
{
DoWork();
}
catch (Exception err)
{
Logging.Log("Exception " + err.ToString());
}
Logging.Log("Finished");
The DoWork() function reads new jobs from a database, and spawns threads to process one work item each. Since last week, the application has started disappearing mysteriously. It disappears from the processes list and there is no entry in the event logs. The log file shows work up to a certain point: it does not log an exception, or the "Finished" line.
Any clue(s) on how a C# application can vanish like that?
EDIT: Threads are created like:
new Thread(SomeObj.StartFunc).Start();
Some of the disappearances occur when no threads are running.
P.S. We installed DebugDiag with a rule to create a crash dump whenever our program crashed. It did not create any dump files when the process disappeared.
You need to have a similar catch block at the top level of the function that every thread works. If there is an uncaught exception on a thread it will kill the application, and the catch block on the main thread is not going to help.
What's the identity that you're using to run the console application?
Also, you might want to use SetConsoleCtrlHandler to capture the console events. Look at this blog post for more details. We had a similar issue when the console application was run under a service account, and it would occasionally get terminated. I'm not sure if this is what you're running into. Let me know I can post some code.
UPDATE: It looks like your scenario resembles what we had experienced. In your console event handler, you need to check for the LogOff event and return true. Look at this KB article.
public static void inputHandler(ConsoleCtrl.ConsoleEvent consoleEvent)
{
if (ConsoleEvent == ConsoleCtrl.ConsoleEvent.CtrlLogOff)
return true;
return false;
}
It's possible that one of the threads that the DoWork method is spawning is throwing an exception. The default behavior in this case is for the process to terminate. You can stop this from happening by using the AppDomain.UnhandledException event to override the default behavior.
A console program quits when the main function exits. Since DoWork just spawns a few threads it's returning control to main right away, and since Main has nothing else to do it exits and the program ends. At this time the threads spawned by DoWork are also killed.
That it worked before means either there was something in DoWork() to wait on those threads that now returns right away (is broken) or that part still works but a thread that used to take a long time to return now aborts and returns right away.
It could perhaps be the Logging.Log function that throws your exception.
I have managed to make programs disappear without a trace in a similar fashion to you (no exception traces and no termination log messages) in the past. Almost all the time it was related to killing the stack (the name of this website always reminds me).
It is possible that you are suddenly trying to process far more data than usual, or using re-entrant routines, or being 'clever' with pointers.
DISCLAIMER: My experience was with a Win32 C++ application, not C#.
It could be a memory leak. If your application takes too much memory, Windows will kill it. You can check how much memory you are using: if it grows over time, you may have a memory leak.
Another possibility is that somewhere, you have code calling Environment.Exit(). Try a full text search through your code to double-check. You never know!
Be careful; there are some exceptions that cannot be caught: OutOfMemoryException and StackOverflowException.
Therefore your program will die terribly, but silently.