I have an application (based on the XNA project template) that in the beginning shows a window so that the user can change some settings. After that the Window is closed and the program continues in another window managed by XNA. Almost exactly 15 minutes after that the program crashes in a thread named Win32 that is not the main thread (but was never spawned by me) with an access violation.
Using the standard debugger there isn't even a stack trace. Using the native debugger it only shows that the access violation occurred in Kernel32!BaseThreadInitThunk which is an undocumented method. At the same time the main thread still seems to be happily executing the main game loop.
Keep in mind that the application is a pure C# application so this is really baffling me.
After some testing I figured out that this even happens if I show an empty window:
Window window = new Window();
window.ShowDialog();
So removing the above two lines in my code makes the program completely stable. Adding them back guarantees the access violation after 15 minutes (+- 30 seconds).
I've checked that the main thread, which spawns the window, is an STA thread. I've also tried to manually start the dispatcher, but that doesn't seem to help (the dispather seems to be already running) and I even tried to shutdown the dispatcher after I showed the window, also to no effect.
I've also tried to show the window using techniques for showing windows in multiple threads described in this answer. But that also had no effect. I even tried launching a completely separate thread to show the window (using the same technique). This also had no effect.
How can these two lines of code make my program crash 15 minutes later? What kind of clean-up of an empty, standard, window could be necessary?
Sounds like a memory related issue from not disposing objects properly...
Related
I Got a WPF Application that hang on random.. (look like thread synchronisation, no CPU Usage / dead lock ??)
When I look at the dump file, the main UI thread is stop on DispatcherSynchronizationContext when OnUserPreferenceChanging() called
see link : https://support.microsoft.com/en-us/help/943139/windows-forms-application-freezes-when-system-settings-are-changed-or
So I use SPY++ to check, I found that I got two thread that have Windows (not mine)
is GDI+ (always present when application running and hang)
is SystemResourceNotifyWindow (always present when is hanged)
The seconds one is causing the problem (I think)
The OnUserPreferenceChanging() is called severa time without hanging (log used)
All controls/windows are created with Dispatcher (Invoke or BeginInvode)
Any way to find when this windows is created ?
Any idea how to fix ?
In any .NET 2.0 Winforms application, if you run the code in Debug Mode, and you either hit a breakpoint or otherwise Step Into the code line by line, and you want to see the GUI of the application being debugged, then .NET does not draw the application screen.
For example, I have an application which writes some messages to a TextBox on a Form. When I debug the code step by step, or when a breakpoint is hit, I want to see what all messages are logged in the TextBox, but if I press Alt-Tab to switch from VS2005 window to the WinForms application window, all I see is white color. The form is not redrawn, until you press F5 in the debug mode in VS2005.
What is the reason for this, and is there a way to overcome this, without introducing any threads in the code?
What is the reason for this
While you're debugging, you're effectively blocking the UI thread - you're manually stepping through its execution flow. The UI thread can't draw the UI while you're stopping it from executing.
and is there a way to overcome this
You could try calling Application.DoEvents() manually, but I'd generally recommend against it.
It would be better to just wait until you got to the end of the method and let the UI redraw itself normally. If your method is very long (in terms of time) then bear in mind that when not debugging, the UI still wouldn't be able to update itself while that method is executing. This may cause you to change your design (it's hard to tell just from the information we've got at the moment).
The reason for this is because you can only have one UI thread, and when you enter your method that updates that code that code begins blocking the UI thread. It will not update until your method exits.
Here is a good SO on message pumps, which are what drive the UI updates
You should be able to use Add Watch/Quick Watch to look at any values at the time of debugging. This sounds like what you are really looking for, anyway.
Like everyone else has said in answers and comments, the UI thread is blocked so it cannot be redrawn.
However, if all you want to do is see the GUI, and not interact with it, and you are running Windows 7/8 (which sounds unlikely since you're using VS2005) and haven't disabled aero peek, you can mouse over your application in the task bar and Windows will show the preview thumbnail. When you mouse over the thumbnail, you can "peek" at the application even when the breakpoint is blocking the UI thread.
I made a program based on Aforge (it's a video library). This library creates its own refresh events for the next video frame from camera. So far so good, earlier people have helped me with multi threading so these Aforge threads could report back to the main program thread, again so far so good, it works great.
The code can be seen here: how to do multithreading when using outside referenced code.
But now I regularly notice a new program error. The problem starts when I want to exit the program. At the moment the Aforge thread might still be active. And it wants to write back to main form that is closed.
Somehow I need to stop the other thread before I close the program. There is an option in Aforge to do something like camera stop, but it's not enough. But then still my code wants to write on the main form that's already closing.
Is there a way to stop all threads, or some safe way to close from the originating thread? I even placed the back reporting to the main program in a try catch construction but it didn't work well, the only way of stopping it in these situations is to press the stop execution button within Visual Studio itself.
If I understand your problem correctly, you may have an Invoke call about to happen on your form just as you've closed the form. I've had this happen as well.
What I've done is to set a "shutdown" variable when I start to close the form, and then use AppDomain.CurrentDomain.UnhandledException to watch for InvalidOperationException (or whatever you're getting), and ignore if shutdown is set.
I've worked on quite a few WPF solutions, and this is the first time i am seeing this problem.
Today it started happening intermittently. where after closing my WPF window, the .exe is still running under visual studio.
so i have to kill my program.exe manually in order to compile again.
Initially i thought because i overrode application start/exit/exception .. but i commented all that out, and it is still happening.
In fact, i see multiple instances of my program.exe in process explorer!
Can't figure out what is causing my exe not to exit. Is there any explicit dipose logic i can add in applicaton exit event to ensure it really exits?
My application consists of single window, and multiple user controls as views.
update
if i open in debug mode. and close the main WPF window, my visual studio does not stop debugging. however call stack window is empty.
You can use the Application.Exit event to log when your application shuts down.
Alternatively, you can attach the debugger to your running instance (even if it wasn't started in the debugger) then pause it to see where it's at. Make sure to look at the Threads tool window, as you may pause outside the UI thread.
This should take care of it, though its probably better to try to figure out the underlying issue.
System.Diagnostics.Process.GetCurrentProcess().Kill();
There is a program where I work that works fine when running the .exe file but works differently from expected when opened in VS2005 and played from there. I am therefore asking on here if anyone knows of anything that would work in the .exe file but not the debug from VS? I am not able to post the code for the buttons I'm talking about but I'll try to explain the best I can.
There is a receiver hooked up to the computer. When the button is pressed on the program, it shows a message and waits for a signal to be received. After the signal is heard the first message box is supposed to close and another is supposed to open. When using the .exe file this happens just fine. However when playing from the program from VS2005 (the same one from which the .exe was made) the second message doesn't come up when it is supposed to and when I can make it come up, the first box doesn't close. There is also a timer involved if that helps.
Also, is there a fundamental difference between how the two operate when executing the program?
If I need to make anything more clear or give more details please let me know.
Running a program under the supervision of a debugger can change the timing of events compared to running the program standalone. The debugger slows things down. Normally, this doesn't make any difference to the operation of the program, but if you have code that is dependent on the "coincidental" rapid timing of some activity, that happy coincidence may be broken when things slow down under debugger control.
The debugger can also cause changes in focus and activation depending on where you set your breakpoints - generally not a good idea to set a breakpoint in focus change or activation events because stopping at the breakpoint will change focus to the debugger, away from your app. But these are interaction issues. Just running your program under the debugger with no breakpoints shouldn't affect focus or activation in your app.
Review your code carefully. Consider what could happen to your program flow if you inserted delays between every source code statement. If that could lead to problems, you have a design bug that needs to be fixed. Reliance on coincidental timings will lead to bug reports and support calls, particularly if your customers have slower hardware than your development machine.
When you run under the debugger, or even in the VS testing host, there are some subtle differences. This shouldn't effect your program under normal circumstances, however, since most of the differences are similar to running (the debug version) of your application on a slower system.
Given your descriptions, I suspect that your problem is actually due to calling to the UI from a different thread than the control was constructed with. Make sure to always marshal any calls to the UI using Control.Invoke or Control.BeginInvoke.
It may be an issue with the Host Process, disabling it is a painless click and just as easy to re-enable. It may be worth giving a try.
Disable Host Process
I know this can effect Direct X and other API but I've never had exactly the situation you are in so I make no promise.