2

I have an issue with my WPF application crashing randomly (but at least twice per day) leaving the following message in windows Application log:

Application: AppName.exe Framework Version: v4.0.30319 Description: The process was terminated due to an internal error in the .NET Runtime at IP xxxxxxxx (xxxxxxxx) with exit code 80131506.

Just to give you the background, this application runs on an embedded system running Windows Embedded Standard 2009, and together with another process is the only application running on the device (even explorer is disabled since it is not needed).

After some trial-and-error investigation, I have isolated the code triggering the error. It is a hook installed on the mainwindow and used to intercept the HWND messages to know when the monitor goes off or in standby mode. Since the system is equipped with a touch panel, I cover my application mainwindow with a panel while the monitor is off so when the user touches the monitor to take it out of standby mode, it won't erroneously click one of the buttons in my mainwindow. When the panel itself gets a "click" event, it closes, disappearing and thus allowing the user to resume normal operativity.

here is how i instantiate the hook and the function that gets called when the hwnd is intercepted:

private void Window_Loaded(object sender, RoutedEventArgs e)
{
    WindowInteropHelper helper = new WindowInteropHelper(this);
    HwndSource.FromHwnd(helper.Handle).AddHook(HwndSourceHookHandler); 
}

private IntPtr HwndSourceHookHandler(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
{
    handled = false;

    if (msg == WM_SYSCOMMAND && wParam == (IntPtr)SC_MONITORPOWER)
    {  
        if (lParam == (IntPtr)MONITOR_OFF || lParam == (IntPtr)MONITOR_STANDBY)
        {
          AppName.Shell.canvasStandBy.Visibility = System.Windows.Visibility.Visible;       
        }
    }
    return IntPtr.Zero;
}

If I comment out the code in the Window_Loaded bit the crash does not happen anymore... Can you point out what is wrong with this code or give me a hint for another way to make it so that the users' clicks on the monitor while it is off do not get to the underlying mainwindow?

Thanks in advance for your help :)

Netrunner
  • 43
  • 5
  • ExecutionEngineException is as bad as they come, you'd have to corrupt internal CLR state. Usually by corrupting the GC heap. Nothing in the snippet that could easily explain that. The alternative you could consider is using Dispatcher.BeginInvoke() so that the Visibility assignment occurs at a more appropriate time. – Hans Passant Nov 22 '13 at 14:17
  • Have you looked at [http://support.microsoft.com/kb/2640103](http://support.microsoft.com/kb/2640103) ? – Suresh Nov 22 '13 at 14:18
  • @sthotakura Yes I have obtained the hotfix mentioned from microsoft a few days ago, applied it to my test system but the error persists unchanged :( – Netrunner Nov 22 '13 at 14:28
  • @HansPassant I will try that, but I strongly doubt that that could solve the problem since the crash happens mostly when the monitor has been OFF for hours (last time was at 4 am this morning, and the last time I touched the screen to turn it on was around 6PM yesterday..) so it shouldn't be related to when the Visibility assignment is being issued, since at that time the panel should have already been visible for hours and I am 100% sure nobody touched the screen at that time :) – Netrunner Nov 22 '13 at 14:31
  • Well, no argument from me, I don't think you found the true cause either. GC heap corruption is very hard to diagnose, you'll be staring at a minidump in Windbg for a while to get close. What makes it so hard to diagnose is that the heap damage is done long before the program crashes. Of course, when a program is entirely idle and not collecting garbage then that can certainly have happened 2 hours ago :) – Hans Passant Nov 22 '13 at 14:46
  • Are you calling any other unmanaged API via P/Invoke, that may be causing this heap corruption? – Suresh Nov 22 '13 at 15:01
  • @sthotakura that was my first idea, that is why I tried taking out firstly all unmanaged calls (i had a few, to be honest, used to set system date/time and audio volumes) but the application was still crashing. So on my final version there is only the hook left and no other P/Invoke, and I still get crashes. If I take the hook out, either reintroducing all the removed P/Invokes or leaving it "clean", I don't get anymore crashes... – Netrunner Nov 22 '13 at 15:04

1 Answers1

0

Worked out the problem. @HansPassant was right. The REAL problem was not with the hook call, but with an external, third party, DLL (containing some custom controls used in the application) that was using some wrongly signed P/INVOKES. The Hook call was just triggering the problem by somehow forcing the Garbage Collector to intervene at times when nobody was using the device and thus detecting the heap corruption that had been there since the custom controls had been instantiated. The solution was: obtaining a newer, fixed DLL from the developer, and the problem is no more :) Thanks everybody for helping.

Netrunner
  • 43
  • 5