Access Violation After Windows Resume from Sleep

Question

I have had a few users report a AV for my application after they close their laptop lid and reopen it. I assume Windows went into Sleep Mode and the problem occurs on resume. It's a standard Windows 32 bit application written in Delphi Seattle 10.

What happens to an application after it wakes up from "sleep"? Anyone have any ideas? How can this be corrected?

Below I've posted the Call Stack which give the error - I cannot see anything particularly wrong,

Steve

Access violation at address 00000000 in module 'AlignMix.exe'. Read of address 00000000.

[011A1B43] dxBarExtItems.TPlaceForm.WMEraseBkgnd (Line 1021, ''dxBarExtItems.pas'')
[0064787D] Vcl.Controls.TControl.WndProc
[0064C3BD] Vcl.Controls.TWinControl.WndProc
[0074B344] Vcl.Forms.TCustomForm.WndProc
[0064B9DC] Vcl.Controls.TWinControl.MainWndProc
[00502E50] System.Classes.StdWndProc
[76CB84F1] user32 (possible SetManipulationInputTarget+81)
[76C96C3B] user32 (possible CallWindowProcW+763)
[76C9681B] user32 (possible DispatchMessageW+1323)
[76C9D167] user32 (possible PeekMessageW+1367)
[77088E54] ntdll.KiUserCallbackDispatcher
[76CB92CA] user32.DestroyWindow
[0064B38C] Vcl.Controls.TWinControl.DestroyWindowHandle
[00BEA26E] cxControls.TcxControl.DestroyWindowHandle (Line 5856, ''cxControls.pas'')
[0064B33D] Vcl.Controls.TWinControl.DestroyWnd
[00C19D6C] cxContainer.TcxContainer.DestroyWnd (Line 3881, ''cxContainer.pas'')
[0064B5C5] Vcl.Controls.TWinControl.DestroyHandle
[0074D5AD] Vcl.Forms.TCustomForm.DestroyHandle
[0064B976] Vcl.Controls.TWinControl.SetParentWindow
[011AD042] dxBarExtItems.TdxBarControlContainerControl.PlaceControl (Line 5230, ''dxBarExtItems.pas'')
[011ACF6A] dxBarExtItems.TdxBarControlContainerControl.InternalPaint (Line 5209, ''dxBarExtItems.pas'')
[011AD542] dxBarExtItems.TdxBarControlContainerControl.DoPaint (Line 5333, ''dxBarExtItems.pas'')
[00C83188] dxBar.TdxBarItem.GetStyleValue (Line 20608, ''dxBar.pas'')
[00CB618D] dxBar.TdxBarItemControl.Paint (Line 41821, ''dxBar.pas'')
[00FC28BA] dxRibbon.TdxRibbonCustomToolbarBarControl.DoPaintItem (Line 8918, ''dxRibbon.pas'')
[00FEB7C0] dxRibbonStatusBar.TdxRibbonStatusBarBarControl.DoPaintItem (Line 522, ''dxRibbonStatusBar.pas'')
[00CBEF57] dxBar.TCustomdxBarControl.PaintItem (Line 45942, ''dxBar.pas'')
[00CBD76E] dxBar.TCustomdxBarControl.DrawItems (Line 45205, ''dxBar.pas'')
[00CC7C50] dxBar.TdxBarControl.DoPaint (Line 49698, ''dxBar.pas'')
[00CC3082] dxBar.TdxBarControl.Paint (Line 47747, ''dxBar.pas'')
[00652503] Vcl.Controls.TCustomControl.PaintWindow
[0064C589] Vcl.Controls.TWinControl.PaintHandler
[0064CD74] Vcl.Controls.TWinControl.WMPaint
[0065249D] Vcl.Controls.TCustomControl.WMPaint
[00CBB22A] dxBar.TCustomdxBarControl.WMPaint (Line 44163, ''dxBar.pas'')
[00FC2B98] dxRibbon.TdxRibbonCustomToolbarBarControl.WMPaint (Line 9007, ''dxRibbon.pas'')
[0064787D] Vcl.Controls.TControl.WndProc
[0064787D] Vcl.Controls.TControl.WndProc
[0064C3BD] Vcl.Controls.TWinControl.WndProc
[00CBBDFF] dxBar.TCustomdxBarControl.WndProc (Line 44477, ''dxBar.pas'')
[00CC521D] dxBar.TdxBarControl.WndProc (Line 48701, ''dxBar.pas'')
[006474B8] Vcl.Controls.TControl.Perform
[00BE1F82] cxControls.dxBufferedPaintControl (Line 2087, ''cxControls.pas'')
[00FC2BE9] dxRibbon.TdxRibbonCustomToolbarBarControl.WMPaint (Line 9016, ''dxRibbon.pas'')
[0064787D] Vcl.Controls.TControl.WndProc
[0064787D] Vcl.Controls.TControl.WndProc
[0064C3BD] Vcl.Controls.TWinControl.WndProc
[00CBBDFF] dxBar.TCustomdxBarControl.WndProc (Line 44477, ''dxBar.pas'')
[00CC521D] dxBar.TdxBarControl.WndProc (Line 48701, ''dxBar.pas'')
[0064B9DC] Vcl.Controls.TWinControl.MainWndProc
[00502E50] System.Classes.StdWndProc
[76CB84F1] user32 (possible SetManipulationInputTarget+81)
[76C96C3B] user32 (possible CallWindowProcW+763)
[76C9681B] user32 (possible DispatchMessageW+1323)
[76C9D167] user32 (possible PeekMessageW+1367)
[77088E54] ntdll.KiUserCallbackDispatcher
[0064F0C5] Vcl.Controls.TWinControl.Update
[0064F0DD] Vcl.Controls.TWinControl.Repaint
[00CAE3E7] dxBar.TdxDockControl.PaintBarControls (Line 38531, ''dxBar.pas'')
[00CAE69A] dxBar.TdxDockControl.UpdateDock (Line 38596, ''dxBar.pas'')
[00CC4B8A] dxBar.TdxBarControl.DoRepaintBar (Line 48491, ''dxBar.pas'')
[00CBE853] dxBar.TCustomdxBarControl.RepaintBarEx (Line 45726, ''dxBar.pas'')
[00CC00AC] dxBar.TCustomdxBarControl.RepaintBar (Line 46422, ''dxBar.pas'')
[00CC8523] dxBar.TdxBarControl.RebuildBar (Line 49912, ''dxBar.pas'')
[00CC781D] dxBar.TdxBarControl.BarManagerStyleChanged (Line 49618, ''dxBar.pas'')
[00C7B545] dxBar.TdxBarManager.InternalStyleChanged (Line 17475, ''dxBar.pas'')
[00C7B5AA] dxBar.TdxBarManager.LFChanged (Line 17492, ''dxBar.pas'')
[00BCA0D8] cxLookAndFeels.TcxLookAndFeel.Changed (Line 589, ''cxLookAndFeels.pas'')
[00BCA670] cxLookAndFeels.TcxLookAndFeel.SystemPaletteChanged (Line 749, ''cxLookAndFeels.pas'')
[00BCB178] cxLookAndFeels.TcxSystemPaletteChangedNotifier.DoChanged (Line 1122, ''cxLookAndFeels.pas'')
[00BC9B95] cxLookAndFeels.TcxSystemPaletteChangedListener.DoChange (Line 431, ''cxLookAndFeels.pas'')
[00BC9BC9] cxLookAndFeels.TcxSystemPaletteChangedListener.WndProc (Line 439, ''cxLookAndFeels.pas'')
[00502E50] System.Classes.StdWndProc
[76CB84F1] user32 (possible SetManipulationInputTarget+81)
[76C96C3B] user32 (possible CallWindowProcW+763)
[76C9681B] user32 (possible DispatchMessageW+1323)
[76C9D167] user32 (possible PeekMessageW+1367)
[77088E54] ntdll.KiUserCallbackDispatcher
[76C95EDE] user32.SendMessageW
[73EB9085] shell32.SHAppBarMessage
[00F985D2] dxRibbonForm.TdxCustomRibbonForm.IsNeedCorrectForAutoHideTaskBar (Line 1271, ''dxRibbonForm.pas'')
[00F98332] dxRibbonForm.TdxCustomRibbonForm.CalculateZoomedOffsets (Line 1197, ''dxRibbonForm.pas'')
[00F99925] dxRibbonForm.TdxCustomRibbonForm.WMNCCalcSize (Line 1917, ''dxRibbonForm.pas'')
[0064787D] Vcl.Controls.TControl.WndProc
[770685E2] -= a recursive area removed =- (Line 2)
[0064C3BD] Vcl.Controls.TWinControl.WndProc
[0064C3BD] Vcl.Controls.TWinControl.WndProc
[0074B344] Vcl.Forms.TCustomForm.WndProc
[00F9A41F] dxRibbonForm.TdxCustomRibbonForm.WndProc (Line 2284, ''dxRibbonForm.pas'')
[00BF08E9] cxControls.TcxWindowProcLinkedObject.DefaultProc (Line 8898, ''cxControls.pas'')
[00C364D9] dxShadowWindow.TdxShadowWindow.OwnerWindowWndProc (Line 375, ''dxShadowWindow.pas'')
[00BF0CBD] cxControls.TcxWindowProcLinkedObjectList.WndProc (Line 9010, ''cxControls.pas'')
[0064B9DC] Vcl.Controls.TWinControl.MainWndProc
[00502E50] System.Classes.StdWndProc
[76CB84F1] user32 (possible SetManipulationInputTarget+81)
[76C96C3B] user32 (possible CallWindowProcW+763)
[76C969D2] user32.CallWindowProcW
[0125F5B9] FormSize.TFormSize.HookWndProc (Line 432, ''FormSize.pas'')
[77055E63] ntdll (possible RtlActivateActivationContextUnsafeFast+211)
[00502E50] System.Classes.StdWndProc
[76CB84F1] user32 (possible SetManipulationInputTarget+81)
[76C96C3B] user32 (possible CallWindowProcW+763)
[76C9681B] user32 (possible DispatchMessageW+1323)
[76C9EC9D] user32 (possible RemovePropW+221)
[77088E54] ntdll.KiUserCallbackDispatcher
[0064787D] Vcl.Controls.TControl.WndProc
[0064C3BD] Vcl.Controls.TWinControl.WndProc
[0074B344] Vcl.Forms.TCustomForm.WndProc
[00F9A41F] dxRibbonForm.TdxCustomRibbonForm.WndProc (Line 2284, ''dxRibbonForm.pas'')
[00BF08E9] cxControls.TcxWindowProcLinkedObject.DefaultProc (Line 8898, ''cxControls.pas'')
[00C364D9] dxShadowWindow.TdxShadowWindow.OwnerWindowWndProc (Line 375, ''dxShadowWindow.pas'')
[00BF0CBD] cxControls.TcxWindowProcLinkedObjectList.WndProc (Line 9010, ''cxControls.pas'')
[0064B9DC] Vcl.Controls.TWinControl.MainWndProc
[00502E50] System.Classes.StdWndProc
[76CB84F1] user32 (possible SetManipulationInputTarget+81)
[76C96C3B] user32 (possible CallWindowProcW+763)
[76C969D2] user32.CallWindowProcW
[0125F5B9] FormSize.TFormSize.HookWndProc (Line 432, ''FormSize.pas'')
[77055E63] ntdll (possible RtlActivateActivationContextUnsafeFast+211)
[00502E50] System.Classes.StdWndProc
[76CB84F1] user32 (possible SetManipulationInputTarget+81)
[76C96C3B] user32 (possible CallWindowProcW+763)
[76C9681B] user32 (possible DispatchMessageW+1323)
[76C9F76E] user32 (possible InitDManipHook+1246)
[77088E54] ntdll.KiUserCallbackDispatcher
[76C9CD7A] user32 (possible PeekMessageW+362)
[007548C0] Vcl.Forms.TApplication.ProcessMessage
[007549E2] Vcl.Forms.TApplication.HandleMessage
[00754D15] Vcl.Forms.TApplication.Run
[0173E485] AlignMix.Initialization (Line 203, ''AlignMix.dpr'')
[75A438F2] KERNEL32.BaseThreadInitThunk

I've never seen this problem. We have our software installed on hundreds of customers' machines. It must be somewhere in your code, or this third-party library you're using. — Jerry Dodge, Sep 27 '16 at 18:33
Some control recreation due to some display setting change.. You can probably emulate in a debug session. — Sertac Akyuz, Sep 27 '16 at 18:41
Indeed, go into debug mode, then go to your display settings, and change, for example, the resolution. — Jerry Dodge, Sep 27 '16 at 18:51
Thanks - looking through the call stack it does seem to be linked to the DevExpress control. I have a container control for the zoom on the task bar. Maybe that has something to do with it. — Steve Maughan, Sep 27 '16 at 21:27
@JerryDodge I have seen this problem many times. But the truth is that it is much more common in video games especially those made by indie developers on their own custom graphical engines. And yes in case of sad games the most common cause for AV is destruction of the rendering handle at the time when OS goes into sleep mode. Same AV can also be raised when PC switches between integrated or dedicated graphics card. Now in OP example I don't know if it is connected with render handle but the cause might rely in the fact that desktop window also gets destroyed when PC goes into sleep mode. .... — SilverWarior, Sep 27 '16 at 21:30
... So if program is constantly accessing data from desktop window or even perhaps of other application windows (name of application suggest that it can be some kind of a window manager) before they are ready. Now debugging of such problem could become very problematic since it can be damn hard to recreate such scenario without screwing the debugger in the process. My best advice is to implement necessary mechanisms for detecting when PC power status changes and act accordingly. This can become extremely important if your application is writing crucial data to HDD to avoid data loss. — SilverWarior, Sep 27 '16 at 21:36
Hmm thinking a bit more on this matter. If the cause lies in the destruction of the desktop window when PC goes to sleep mode you could simulate that by forcing your application window to be child window of another window belonging to another application which is then closed so that its window is destroyed. — SilverWarior, Sep 27 '16 at 21:41
@Silver - You're thinking too much ;), monitors may get detached/attached due to driver issues/orphaned configs, but the desktop remains., — Sertac Akyuz, Sep 27 '16 at 22:14
I remember old Opera Presto used to hang up and almost destroy WinGDI when computer went out of hibernation. Later they somehow fixed it. It was not VCL nor Delphi and I dunno if someone ever knows what was the reason nor if that is related — Arioch 'The, Sep 27 '16 at 22:32
"[011A1B43] dxBarExtItems.TPlaceForm.WMEraseBkgnd (Line 1021, ''dxBarExtItems.pas'')" So, providing you do have licensed DevExpress please - quote this line and few lines before and after. And go to DevExpress support forum - they usually do pay some attention there — Arioch 'The, Sep 27 '16 at 22:33
@SertacAkyuz but I guess going in/out of hiber the Windows switched from the usual desktop and drivers and goes into SafeVGA and special desktop to play that "suspending" animation (in win8 they replaced it with black screen, but underlying technology should remain) and "recovering" animation. Thus some DX surfaces may truly be lost. That say, for what I know DevWEx do not use Direct 2D, but they heavily use GDI+ — Arioch 'The, Sep 27 '16 at 22:38
I guess it depends on the configuration of the user account. Do you require a password to login to Windows? Does Windows show a lock screen after hibernation regardless of not having a password? — Jerry Dodge, Sep 28 '16 at 00:32
@Arioch'The So is it safe to also assume GDI+ might be the culprit? — Jerry Dodge, Sep 28 '16 at 00:34
@JerryDodge GDI+ is a black box - only MS knows what is there inside. Personally I do not see the reason GDI+ should act like this (being CPU-oriented library, not GPU-oriented), but.... we do not have a lot of plausible versions anyway. — Arioch 'The, Sep 29 '16 at 08:37
Wow, so much pointless speculation. You just need to debug this. — David Heffernan, Sep 29 '16 at 20:50

Access Violation After Windows Resume from Sleep

0 Answers0