System.Runtime.InteropServices.ExternalException : A generic error occurred in GDI+

[StefanKoell]

• .NET Core Version:
  Microsoft.WindowsDesktop.App 5.0.9

• Have you experienced this same bug with .NET Framework?:
  No

Problem description:
I switched my WinForms App from .NET 4.71 to .NET 5 and get the following crashes from my user's machine:

System.Runtime.InteropServices.ExternalException: A generic error occurred in GDI+.
Source: System.Drawing.Common
    -- get_ErrorCode = -2147467259 (0x80004005)   [int]
    -- get_HResult = -2147467259 (0x80004005)   [int]
 at [System.Drawing.Common] System.Drawing.Graphics void CheckErrorStatus(int )
 at [System.Drawing.Common] System.Drawing.Graphics void FillRectangle(System.Drawing.Brush ,System.Drawing.Rectangle )

From the stack trace, I can see that this crash almost always originates from showing a messagebox (drawing the background). Since I'm not able to reproduce the crash myself, I reached out to my users and I was at least able to find a common pattern:

• Many users told me that the crash happens when the machine has been in sleep mode and wakes up. My app would show a message box when a network connection is interrupted, so this makes sense.
• Some users reported that the crash happens when Windows tries to shutdown/reboot while my app is running.
• Some users reported that the crash happens when my app is set to auto-run and shows the first dialog (password prompt). In this case it seems that the app has been started while the login screen is still shown.

Judging from the user reports, I guess this crash mostly happens when the "desktop" is "hidden" or not shown (like lock screen when the machine enters sleep mode, login screen, the screen shown when you shutdown/reboot Windows).

I'm not sure how to further troubleshoot the issue or resolve the issue.

Minimal repro:
Unfortunately I'm not able to reliably reproduce the issue myself.

[kirsan31]

Interesting...
Can you post some more (and a beet deeper) stack traces?
We faced a similar problems.
Long story...
Such errors never happens on .Net472.
After we switched to .NetCore 3.1, we have several such errors (during a year) only on Windows7 machine:

UnhandledException details: System.Runtime.InteropServices.ExternalException (0x80004005): A generic error occurred in GDI+.
   at System.Drawing.Graphics.CheckErrorStatus(Int32 status)
   at System.Drawing.Graphics.DrawLine(Pen pen, Int32 x1, Int32 y1, Int32 x2, Int32 y2)
   at ...FrmBase.WndProc(Message& m) in ...
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, WM msg, IntPtr wparam, IntPtr lparam)

WndProc (override in Form class) is something like this:

protected override void WndProc(ref System.Windows.Forms.Message m)
{
    base.WndProc(ref m);

    IntPtr hdc = WinApi.User32.GetWindowDC(m.HWnd);
    if (hdc == IntPtr.Zero)
        return;

    using (Graphics g = Graphics.FromHdc(hdc))
    {
        g.DrawLine(ErrorPen, 0, 0, this.Width, 0);
    }
    WinApi.User32.ReleaseDC(m.HWnd, hdc);
}

After we switched to .Net5, this error began to appear several times a day, but again only on windows7 machine.
Since I was not able to provide a 100% reproduction method, I did not report it.

Also on .Net5, several times (win 10) we got this:

UnhandledException details: System.Runtime.InteropServices.ExternalException (0x80004005): A generic error occurred in GDI+.
   at System.Drawing.Graphics.CheckErrorStatus(Int32 status)
   at System.Drawing.Graphics.FillRectangle(Brush brush, Int32 x, Int32 y, Int32 width, Int32 height)
   at System.Windows.Forms.ToolStripTextBox.ToolStripTextBoxControl.WmNCPaint(Message& m)
   at System.Windows.Forms.ToolStripTextBox.ToolStripTextBoxControl.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, WM msg, IntPtr wparam, IntPtr lparam)
   at Interop.User32.CallWindowProcW(IntPtr wndProc, IntPtr hWnd, WM msg, IntPtr wParam, IntPtr lParam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.Control.DefWndProc(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.TextBoxBase.WndProc(Message& m)
   at System.Windows.Forms.TextBox.WndProc(Message& m)
   at System.Windows.Forms.ToolStripTextBox.ToolStripTextBoxControl.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, WM msg, IntPtr wparam, IntPtr lparam)
   at Interop.User32.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.Interop.Mso.IMsoComponentManager.FPushMessageLoop(UIntPtr dwComponentID, msoloop uReason, Void* pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(msoloop reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(msoloop reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)

and this one looks more similar to yours...

Judging from the user reports, I guess this crash mostly happens when the "desktop" is "hidden" or not shown (like lock screen when the machine enters sleep mode, login screen, the screen shown when you shutdown/reboot Windows).

We connect through RDP (connect/disconnect several times a day ~4-20), so most likely something like that.

[StefanKoell]

Nice to see that I'm not alone!

I don't have any of these reports from Windows 7 machines. This could mean that it doesn't exist on Windows 7 or my user base doesn't use Windows 7 anymore.

As for deeper stack traces, here's one:

System.Runtime.InteropServices.ExternalException: A generic error occurred in GDI+.
Source: System.Drawing.Common
    -- get_ErrorCode = -2147467259 (0x80004005)   [int]
    -- get_HResult = -2147467259 (0x80004005)   [int]
 at [System.Drawing.Common] System.Drawing.Graphics void CheckErrorStatus(int )
 at [System.Drawing.Common] System.Drawing.Graphics void FillRectangle(System.Drawing.Brush ,System.Drawing.Rectangle )
 at [DevExpress.Utils.v21.1] DevExpress.Utils.Paint.XPaint void FillRectangle(System.Drawing.Graphics ,System.Drawing.Brush ,System.Drawing.Rectangle )
 at [DevExpress.Utils.v21.1] DevExpress.Skins.SkinElementPainter void FillSkinBackground(DevExpress.Utils.Drawing.ObjectInfoArgs ,DevExpress.Skins.SkinElement )
 at [DevExpress.Utils.v21.1] DevExpress.Skins.SkinElementPainter void DrawObject(DevExpress.Utils.Drawing.ObjectInfoArgs )
 at [DevExpress.Utils.v21.1] DevExpress.Utils.Drawing.ObjectPainter void DrawObject(DevExpress.Utils.Drawing.GraphicsCache ,DevExpress.Utils.Drawing.ObjectPainter ,DevExpress.Utils.Drawing.ObjectInfoArgs )
 at [DevExpress.Utils.v21.1] DevExpress.XtraEditors.FormShowHelperBase void ProcessPaintBackground(System.Windows.Forms.Message )
 at [DevExpress.Utils.v21.1] DevExpress.XtraEditors.FormShowHelperBase void WndProc(System.Windows.Forms.Message )
 at [DevExpress.Utils.v21.1] DevExpress.XtraEditors.XtraForm void WndProc(System.Windows.Forms.Message& )
 at [DevExpress.XtraEditors.v21.1] DevExpress.XtraEditors.XtraBaseForm void WndProc(System.Windows.Forms.Message& )
 at [System.Windows.Forms] System.Windows.Forms.Control/ControlNativeWindow void WndProc(System.Windows.Forms.Message& )
 at [System.Windows.Forms] System.Windows.Forms.NativeWindow System.IntPtr Callback(System.IntPtr ,Interop+User32/WM ,System.IntPtr ,System.IntPtr )

I'm also using the DevExpress UI libraries but I also have seen stacktraces like yours, pure WinForms. Since the FillRectangle method seems to be a common entry point for most stack traces I get, I guess it has something to do with the GDI graphics context when Windows shows a non interactive desktop, such as the lock, login or shutdown screen.

I hope someone can shed some light on the error and on how to further troubleshoot the issue. If I know which data I should collect, I could try to attach this to my crash reports for further investigation.

[StefanKoell]

Well, I just looked at the CheckErrorStatus method in the framework code and found this comment in Graphics.Windows.cs:

///

/// GDI+ will return a 'generic error' with specific win32 last error codes when
/// a terminal server session has been closed, minimized, etc... We don't want
/// to throw when this happens, so we'll guard against this by looking at the
/// 'last win32 error code' and checking to see if it is either 1) access denied
/// or 2) proc not found and then ignore it.
/// The problem is that when you lock the machine, the secure desktop is enabled and
/// rendering fails which is expected (since the app doesn't have permission to draw
/// on the secure desktop). Not sure if there's anything you can do, short of catching
/// the desktop switch message and absorbing all the exceptions that get thrown while
/// it's the secure desktop.
///

I couldn't find this file in the github repo but if you navigate to a FillRectangle call in your code using JetBrains Rider and navigate to the definition, you will get to that code (and comment).

Now I'm really confused how this could have worked in .NET Framework 4.71. I guess there has been code in place which took this scenario into account. I'm wondering why this hasn't been ported or handled properly. Anyone has some more information?

[kirsan31]

It seems that CheckErrorStatus is defiantly here to protect us from what happens in this topic :) But for some reason in core it's not always working...
The code of CheckErrorStatus doesn't changed:

.Net Framework:

private void CheckErrorStatus(int status) {
    if (status != SafeNativeMethods.Gdip.Ok) {
        // Generic error from GDI+ can be GenericError or Win32Error.
        if (status == SafeNativeMethods.Gdip.GenericError || status == SafeNativeMethods.Gdip.Win32Error) {
            int error = Marshal.GetLastWin32Error();
            if (error == SafeNativeMethods.ERROR_ACCESS_DENIED || error == SafeNativeMethods.ERROR_PROC_NOT_FOUND || 
                    //here, we'll check to see if we are in a term. session...
                    (((UnsafeNativeMethods.GetSystemMetrics(NativeMethods.SM_REMOTESESSION) & 0x00000001) != 0) && (error == 0))) {
                    return;
                }
            }

        //legitimate error, throw our status exception
        throw SafeNativeMethods.Gdip.StatusException(status);
    }
}

.Net5:

private void CheckErrorStatus(int status)
{
    if (status == Gdip.Ok)
        return;

    // Generic error from GDI+ can be GenericError or Win32Error.
    if (status == Gdip.GenericError || status == Gdip.Win32Error)
    {
        int error = Marshal.GetLastWin32Error();
        if (error == SafeNativeMethods.ERROR_ACCESS_DENIED || error == SafeNativeMethods.ERROR_PROC_NOT_FOUND ||
                // Here, we'll check to see if we are in a terminal services session...
                (((UnsafeNativeMethods.GetSystemMetrics(NativeMethods.SM_REMOTESESSION) & 0x00000001) != 0) && (error == 0)))
        {
            return;
        }
    }

    // Legitimate error, throw our status exception.
    throw Gdip.StatusException(status);
}

[StefanKoell]

I see. I find it really strange how this can work in .NET 4.71 without a single crash and not always work in .NET 5 with so many crashes. The status, which is passed into the CheckErrorStatus method is the result of the native GDI+ FillRectangle method which I assume is the same in both frameworks.

[kirsan31]

I see. I find it really strange how this can work in .NET 4.71 without a single crash and not always work in .NET 5 with so many crashes. The status, which is passed into the CheckErrorStatus method is the result of the native GDI+ FillRectangle method which I assume is the same in both frameworks.

My guess is that in core GetLastWin32Error can return somthing different than in .Net Framework?

.Net Framework:

[DllImport(ExternDll.Gdiplus, SetLastError=true, ExactSpelling=true, CharSet=System.Runtime.InteropServices.CharSet.Unicode)] // 3 = Unicode
            [ResourceExposure(ResourceScope.None)]
            internal static extern int GdipFillRectangleI(HandleRef graphics, HandleRef brush, int x, int y,
                                                          int width, int height);

.net5:

[DllImport(LibraryName, ExactSpelling = true)]
internal static extern int GdipFillRectangleI(HandleRef graphics, HandleRef brush, int x, int y, int width, int height);

In .net I see no SetLastError=true (on all of imports there)...

[StefanKoell]

Good catch! I hope that someone at MS (@OliaG) can take a look at it.

[RussKie]

It is plausible that the missing SetLastError attribute is the cause, but without a stand alone repro there would be a lot of speculations, and very difficult convince the ship room to allow servicing of .NET 6.0 (RC2 is almost complete) let alone 5.0...

System.Drawing.Common belongs to dotnet/runtime, moving there.

[StefanKoell]

@RussKie If I can get a hand on a special build with this attribute, I could roll that out to my users in order to find out if it resolves the issue. Unfortunately I'm not able to provide a stand alone repro. I'm not sure what other condition must be met to get the crash. I haven't been able to reproduce the crash on my machines.

[RussKie]

You can try the following:

1. clone release/5.0 branch,
2. change the code,
3. build (instructions), and then
4. use your private binary.

[kirsan31]

It is plausible that the missing SetLastError attribute is the cause, but without a stand alone repro there would be a lot of speculations, and very difficult convince the ship room to allow servicing of .NET 6.0 (RC2 is almost complete) let alone 5.0...

System.Drawing.Common belongs to dotnet/runtime, moving there.

Due to that it's related to terminal server session closing/suspending it's a bit difficult to build repro :(
But calling GetLastWin32Error after unmanaged function without SetLastError flag it's a bug any way. I'm not even talking about the fact that the absence of SetLastError here is a bug by itself.

[StefanKoell]

@RussKie I tried what you suggested and even though some errors appear when I build the System.Drawing.Common solution, I do get an assembly in the net5.0-Release folder in the artifacts. Unfortunately, replacing this dll with the one I ship my product makes the app faulty. I can briefly see the process starting but it then disappears with no logs in the event log.

I also adapted the deps.json file in my app directory to pickup the correct file version from the new build (which is oddly 42.42.42.42424).

How can I include/ship my app with the manually compiled version?

Also, regarding the SetLastError flag: I checked the docs here:
https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.marshal.getlastwin32error?view=net-5.0

In the Remarks section I can find the following:
There is a difference in the behavior of the GetLastWin32Error method on .NET Core and .NET Framework when DllImportAttribute.SetLastError is true. On .NET Framework, the GetLastWin32Error method can retain error information from one P/Invoke call to the next. On .NET Core, error information is cleared before P/Invoke call, and the GetLastWin32Error represents only error information from the last method call.

I'm not sure I fully understand the implication but there seems to be a related issue (quite fresh):
#51600

So is the missing SetLastError in the DllImport attribute really a bug?