6

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?

Community
  • 1
  • 1
Roy T.
  • 9,429
  • 2
  • 48
  • 70
  • 1
    Oh I just noticed you are using `ShowDialog()`. Try using `Show()` instead. WPF generally wants to terminate your app when the last WPF window/dialog is closed. Let me know how you go, there are some tricks you can use so that you can still use `ShowDialog` but ensure that WPF won't shutdown your app afterwards –  May 27 '16 at 07:09
  • I've also tried using show and close (even show and hide). It had no effect. I think WPF only tries to close your app if you have an `Application` instance which is the owner of the windows and has the `ShutdownMode` set to `OnLastWindowClose`. Curious to what other ideas you have :) – Roy T. May 27 '16 at 07:15
  • Rats, I was hoping that was it. Let me think some more. Your blog is very cool. I like your balancing creature :) –  May 27 '16 at 07:21
  • Would you be able to show some more of the code from the window, how does it access the applications settings? (I'm assuming that's what it does of course). I had a similar problem and it was basically because of a thread creation issue, I've also seen a similar problem that stems from the way data is stored in the applications settings. Thank you in advance. – JoeTomks Jun 13 '16 at 10:20
  • I have run in to this issue when developing with COM objects in PowerShell and it turned out to be that I wasn't disposing my resources. Are you disposing of the window properly when the user is finished? – Ingenioushax Jun 24 '16 at 22:05
  • @RoyT. Did you ever resolve this? I'm working on a WPF + XNA app and am experiencing something almost exactly the same (Crash always occurs ~14-15m in, AccessViolation). Interested in any progress you've seen on that. – Tomwa Oct 07 '16 at 23:51
  • @Tomwa we mitigated it by moving all our audio from XACT to Fmod, but we're not sure if that really was the cause of the problems – Roy T. Oct 10 '16 at 08:30
  • @RoyT. Thanks, the XNA code in this instance isn't my own (so I can't move from XACT) I did however move from WPF to WinForms for the UI which seems to have corrected the issue. Thanks for the answer. – Tomwa Oct 11 '16 at 05:47

1 Answers1

0

Sounds like a memory related issue from not disposing objects properly...

MattE
  • 1,044
  • 1
  • 14
  • 34