SpDrawIconShadow — `EOutOfResources: "The handle is invalid"` after the system resumes from sleep (confirmed in 2.5.12)

[rubydenial]

Hi,

Thanks for SpTBXLib. We use it in a Delphi 10.3.3 (Rio) application on Windows 11 x64 and traced an intermittent crash to SpDrawIconShadow.

We ship SpTBXLib 2.5.11. We also compared it against the latest release, 2.5.12: the SpDrawIconShadow code is identical, so the issue is still present in 2.5.12.

Where

SpDrawIconShadow (added by the TB2K patch to TB2Common.pas). It is reached for disabled icons over a classic (non-virtual) TImageList:

TSpTBXItemViewer.DrawItemImage -> SpDrawXPMenuItemImage
  -> SpDrawVirtualImageList(..., Enabled = False) -> SpDrawIconShadow

What happens

SpDrawIconShadow builds its two work bitmaps with TBitmap, pf32bit + SetSize:

B1.PixelFormat := pf32bit;  B1.SetSize(ImageWidth, ImageHeight);   // + B2

For a 32-bit bitmap, TBitmap.SetSize goes through Vcl.Graphics.CopyBitmap, which does
GetDC(0), CreateCompatibleDC(ScreenDC) and CreateDIBSection(ScreenDC, ...), each
GDICheck-wrapped. If the screen DC is momentarily unusable, the call returns 0 and VCL
raises EOutOfResources(SysErrorMessage(GetLastError)).

When

On the first toolbar repaint right after the machine resumes from a long sleep/hibernate
(a synchronous TSpTBXDock.Resize -> Update -> WM_PAINT). At that moment:

• the per-process GDI handle count is low (~465, far from the 10,000 limit) — so it is not
  GDI exhaustion;
• GetLastError is ERROR_INVALID_HANDLE (6) — the screen DC is transiently invalid
  while the graphics subsystem is still settling after resume.

SpDrawIconShadow -> TBitmap.SetSize -> CopyImage -> CopyBitmap -> GDICheck
  -> EOutOfResources("The handle is invalid")

Only disabled icons hit it, because SpDrawIconShadow is the only place that allocates a
screen-DC-dependent bitmap during WM_PAINT. Ordinary controls paint into the
BeginPaint DC and are unaffected.

Example: a real crash report

One of our captured crash logs (top frames; the repetitive lower message-loop frames are
omitted). It shows the synchronous TSpTBXDock.Resize -> Update -> WM_PAINT chain reaching
SpDrawIconShadow -> TBitmap.SetSize, where the VCL GDICheck raises the exception.
TicToolbar / BufferedPaint are our thin TB2K toolbar subclass and buffered-paint helper;
the failing path is entirely inside SpTBXLib + VCL:

EOutOfResources: The handle is invalid.

  System._RaiseExcept
  Vcl.Graphics.TCanvas.BrushChanged
  Vcl.Graphics.CreateGrayMappedRes           + $2D1
  Vcl.Graphics.TBitmap.CopyImage             + $BC
  Vcl.Graphics.TBitmap.SetSize               + $67
  Tb2common.SpDrawIconShadow                 + $CB     <-- pf32bit + SetSize buffers
  Tb2common.SpDrawVirtualImageList           + $6D8
  Sptbxitem.SpDrawXPMenuItemImage            + $131
  Sptbxitem.TSpTBXItemViewer.DrawItemImage   + $184
  Sptbxitem.TSpTBXItemViewer.Paint           + $FAF
  Tb2item.TTBView.DrawItem                   + $518
  Tb2item.TTBView.DrawSubitems               + $87
  Tb2toolbar.TTBCustomToolbar.Paint          + $9D
  Icmenucontrols.TicToolbar.Paint            + $179    (our TB2K toolbar subclass)
  Vcl.Controls.TCustomControl.PaintWindow
  Vcl.Controls.TWinControl.PaintHandler
  Icvclutils.BufferedPaint                   + $144    (our buffered-paint helper)
  Icmenucontrols.TicToolbar.WMPaint          + $1D
  ... (TObject.Dispatch / WndProc -> WM_PAINT) ...
  Vcl.Controls.TWinControl.Update            + $20
  Sptbxitem.TSpTBXDock.Resize                + $27A    <-- resize after the system resumed
  Vcl.Controls.TWinControl.AlignControls
  Vcl.Forms.TCustomForm.WndProc
  ... (message loop) ...
  Vcl.Forms.TApplication.Run
  IDE.IDE (Line 324)

What we tried

We did not find a clean fix on our side, so we are leaving the proper fix to you. For the
record, the obvious idea — allocating the buffers without the screen DC via
B1.Handle := CreateDIBSection(0, ...) — does not help: once an external handle is
assigned, VCL GetHandleType reports the bitmap as a DDB, so a later ScanLine calls
DIBNeeded -> CopyBitmap -> GetDC(0) again (and re-copies the bits). In other words, both
SetSize and Handle := <DIB> route a ScanLine-able TBitmap back through GetDC(0).

Environment

SpTBXLib 2.5.11 (in production) — also verified present in the current 2.5.12; Delphi 10.3.3 Rio (RTL/VCL 26.0); Windows 11 x64.

Thank you for maintaining SpTBXLib!

[rubydenial]

Follow-up: a proposed fix

We've implemented a fix on our side — it ships in our Express Pro ERP suite (developer: It-Integrator) — and we'd like to offer it upstream.

Recap of the root cause: SpDrawIconShadow allocates its pf32bit work bitmaps with TBitmap.SetSize, which routes through GetDC(0) + CreateDIBSection on the screen DC. Right after the system resumes from sleep/hibernate that screen DC is transiently invalid, so the VCL GDICheck turns the failure into EOutOfResources("The handle is invalid") and the whole toolbar paint crashes.

Our approach: before allocating those bitmaps, probe whether the screen DC is usable right now by issuing the exact same calls directly — GetDC(0) + a 1×1 CreateDIBSection — but without GDICheck, so a transient failure simply returns False instead of raising. If it isn't ready, we skip the shadow and draw the plain icon straight onto the (valid) canvas; the next repaint, once the graphics subsystem has settled, produces the proper shadow. The probe is intentionally minimal — it's the very call that fails, so relative to SpDrawIconShadow's own per-pixel work it is practically free.

function SpIsScreenDCReady: Boolean;
// It-Integrator: Returns True if the screen DC is currently usable for creating
// screen-compatible (DIB) bitmaps. Right after the system resumes from sleep/
// hibernation the screen DC is transiently invalid; at that moment TBitmap.SetSize
// in the VCL (-> CopyBitmap -> GetDC(0)/CreateDIBSection, all wrapped in GDICheck)
// raises EOutOfResources "The handle is invalid". We probe the very same WinAPI
// calls directly (without GDICheck => without raising) and report readiness, so the
// caller can skip the screen-DC-dependent path until the graphics subsystem settles.
// The probe is intentionally minimal: just GetDC(0) + CreateDIBSection(1x1) (exactly
// the call that fails), so relative to SpDrawIconShadow's own work it is practically free.
var
  ScreenDC: HDC;
  DIB: HBITMAP;
  BI: TBitmapInfo;
  Bits: Pointer;
begin
  Result := False;
  ScreenDC := GetDC(0);
  if ScreenDC = 0 then
    Exit;
  try
    FillChar(BI, SizeOf(BI), 0);
    BI.bmiHeader.biSize := SizeOf(TBitmapInfoHeader);
    BI.bmiHeader.biWidth := 1;
    BI.bmiHeader.biHeight := 1;
    BI.bmiHeader.biPlanes := 1;
    BI.bmiHeader.biBitCount := 32;
    BI.bmiHeader.biCompression := BI_RGB;
    Bits := nil;
    DIB := CreateDIBSection(ScreenDC, BI, DIB_RGB_COLORS, Bits, 0, 0);
    if DIB <> 0 then begin
      DeleteObject(DIB);
      Result := True;
    end;
  finally
    ReleaseDC(0, ScreenDC);
  end;
end;

procedure SpDrawIconShadow(ACanvas: TCanvas; const ARect: TRect;
  ImageList: TCustomImageList; ImageIndex: Integer);
// Used by Office XP skin, to paint a shadow of the glyphs
var
  ImageWidth, ImageHeight: Integer;
  I, J: Integer;
  Src, Dst: ^Cardinal;
  S, C, CBRB, CBG: Cardinal;
  B1, B2: TBitmap;
begin
  ImageWidth := ARect.Right - ARect.Left;
  ImageHeight := ARect.Bottom - ARect.Top;

  // It-Integrator: The disabled-icon shadow builds pf32bit + SetSize work bitmaps,
  // which go through GetDC(0)/CreateDIBSection on the screen DC. Right after resume
  // from sleep that DC is transiently invalid and SetSize raises EOutOfResources
  // "The handle is invalid". If the screen DC is not ready yet, skip the shadow and
  // draw the plain icon straight onto the (valid) canvas; the next repaint will draw
  // the proper shadow.
  if not SpIsScreenDCReady then begin
    if Assigned(ImageList) and (ImageIndex > -1) and (ImageIndex < ImageList.Count) then
      ImageList.Draw(ACanvas, ARect.Left, ARect.Top, ImageIndex);
    Exit;
  end;

  B1 := TBitmap.Create;
  B2 := TBitmap.Create;
  try
    B1.PixelFormat := pf32bit;
    B2.PixelFormat := pf32bit;
    // ... rest of SpDrawIconShadow unchanged ...

Notes / trade-offs

• Graceful degradation: for at most one repaint right after resume, a disabled icon is drawn without its shadow; it self-heals on the next paint. No crash, no blank toolbar.
• This avoids the dead end of assigning an external DIB to TBitmap.Handle: the VCL then reports the bitmap as a DDB (GetHandleType), so a later ScanLine routes back through GetDC(0) anyway (and re-copies the bits) — that doesn't help.
• If you'd rather not run the probe on every disabled-icon paint, it could be gated — e.g. only after a WM_POWERBROADCAST/PBT_APMRESUMESUSPEND, or cache readiness for a short window. We kept it unconditional for simplicity and because the probe is so cheap; happy to adjust to your preference.

Tested in Delphi 10.3.3 Rio, Windows 11 x64. Glad to open a PR if that's easier to review.

[SilverpointDev]

Can't reproduce.
Are you doing something special on Icvclutils.BufferedPaint, or Icmenucontrols.TicToolbar.Paint?
Try to reproduce the error on a new clean project using only SpTBXLib controls.

EOutOfResources: The handle is invalid.
...
  Tb2common.SpDrawIconShadow                 + $CB     <-- pf32bit + SetSize buffers
...
  Icmenucontrols.TicToolbar.Paint            + $179    (our TB2K toolbar subclass)
...
  Icvclutils.BufferedPaint                   + $144    (our buffered-paint helper)
...
  Sptbxitem.TSpTBXDock.Resize                + $27A    <-- resize after the system resumed
...