Analyzing Outlook HANG dump (with GoogleCalendarSync add-in installed) - outlook

Since I started using outlook with GoogleCalendarSync i'm experiencing hangs every once in awhile.
I used ADPlus to create a hang dump of the process (using adplus -hang -pn outlook.exe -o c:\dumps).
When I read the dump via WinDBG I use the command !analyze -v -hang, but I can't figure out what exactly went wrong.
The output of the command is:
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
FAULTING_IP:
+1d32faf00ffdf58 00000000 ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000 ExceptionCode: 80000007 (Wake debugger)
ExceptionFlags: 00000000 NumberParameters: 0
BUGCHECK_STR: HANG
PROCESS_NAME: OUTLOOK.EXE
ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code
text>
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
MANAGED_STACK: !dumpstack -EE OS Thread Id: 0xd60 (37) Current frame:
ChildEBP RetAddr Caller,Callee
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- -------------------------- 0 ba0.6a4 Thread Handle --> 37 ba0.d60 Event
WAIT_CHAIN_COMMAND: ~0s;k;;~37s;k;;
BLOCKING_THREAD: 00000d60
DEFAULT_BUCKET_ID: APPLICATION_HANG_BlockedOn_EventHandle
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BlockedOn_EventHandle
LAST_CONTROL_TRANSFER: from 7c90df5a to 7c90e514
FAULTING_THREAD: 00000025
STACK_TEXT: 11f3f764 7c90df5a 7c8025db 00000458 00000000
ntdll!KiFastSystemCallRet 11f3f768 7c8025db 00000458 00000000 00000000
ntdll!NtWaitForSingleObject+0xc 11f3f7cc 7c802542 00000458 ffffffff
00000000 kernel32!WaitForSingleObjectEx+0xa8 11f3f7e0 77520197
00000458 ffffffff 00192888 kernel32!WaitForSingleObject+0x12 11f3f7fc
77602e50 00192888 001a3ab8 00000000 ole32!GetToSTA+0x6f 11f3f81c
7760208a 11f3f8e4 11f3f9f4 09b148b8
ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0xf6 11f3f8fc
7752c982 09b148b8 11f3f9f4 11f3f9e4
ole32!CRpcChannelBuffer::SendReceive2+0xc8 11f3f968 7752c91a 09b148b8
11f3f9f4 11f3f9e4 ole32!CAptRpcChnl::SendReceive+0xab 11f3f9bc
77ef5db5 09b148b8 11f3f9f4 11f3f9e4
ole32!CCtxComChnl::SendReceive+0x113 11f3f9d8 77ef5ead 09b22354
11f3fa20 0600015b rpcrt4!NdrProxySendReceive+0x43 11f3fdbc 77ef5e42
774e6228 774e92da 11f3fdf4 rpcrt4!NdrClientCall2+0x1fa 11f3fddc
77e88519 00000010 00000005 11f3fe04 rpcrt4!ObjectStublessClient+0x8b
11f3fdec 7752d919 09b22354 00000001 145bf7b8 rpcrt4!ObjectStubless+0xf
11f3fe04 7752d8ba 09b22354 00192888 00000001
ole32!RemoteReleaseRifRefHelper+0x84 11f3fe2c 7752c558 09b22354
00192888 00000001 ole32!RemoteReleaseRifRef+0x74 11f3fe84 7752c351
0e8a3cfc 0e8a3cf8 00000000 ole32!CStdMarshal::DisconnectCliIPIDs+0x200
11f3feac 7750c880 00000002 0e8a3da0 0e8a3cf8
ole32!CStdMarshal::Disconnect+0x178 11f3fec8 7750c7ed 0e8a3cf8
11f3fee8 7750c967 ole32!CStdIdentity::~CStdIdentity+0x89 11f3fed4
7750c967 00000001 00440023 00520006 ole32!CStdIdentity::`vector
deleting destructor'+0xd 11f3fee8 77ef5ae8 80000000 11f3ff00 1112f31b
ole32!CStdIdentity::CInternalUnk::Release+0x4c 11f3fef4 1112f31b
0e8bd1fc 11f3ff14 1112a0e4 rpcrt4!IUnknown_Release_Proxy+0x11 WARNING:
Stack unwind information not available. Following frames may be wrong.
11f3ff00 1112a0e4 11f3ff80 00000000 11f3ff80 GoogleCalendarSync+0xf31b
11f3ff14 1112a0b1 00000000 11f3ff80 11f3ffb4 GoogleCalendarSync+0xa0e4
11f3ff24 11137c5e 555047c9 00020048 80578cb2 GoogleCalendarSync+0xa0b1
11f3ffb4 7c80b729 00000301 00440023 00520006
GoogleCalendarSync+0x17c5e 11f3ffec 00000000 111378c0 00000301
00000000 kernel32!BaseThreadStart+0x37
FOLLOWUP_IP: GoogleCalendarSync+f31b 1112f31b 8b5508 mov
edx,dword ptr [ebp+8]
SYMBOL_STACK_INDEX: 15
SYMBOL_NAME: GoogleCalendarSync+f31b
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: GoogleCalendarSync
IMAGE_NAME: GoogleCalendarSync.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4d9f0466
STACK_COMMAND: ~37s ; kb
BUCKET_ID: HANG_GoogleCalendarSync+f31b
WATSON_IBUCKET: -1362224887
WATSON_IBUCKETTABLE: 1
FAILURE_BUCKET_ID:
APPLICATION_HANG_BlockedOn_EventHandle_cfffffff_GoogleCalendarSync.dll!Unknown
WATSON_STAGEONE_URL:
http://watson.microsoft.com/StageOne/OUTLOOK_EXE/14_0_6117_5001/4f3e2d20/unknown/0_0_0_0/bbbbbbb4/cfffffff/00000000.htm?Retriage=1
Followup: MachineOwner
---------------------------
How can I further investigate this dump? What am I missing?

The thread GoogleCalendarSync is operating in tries to Release a COM object whose apartement model is STA, that is the object lives in a single thread. This kind of object was very popular in the begining of COM, because the COM layer ensures the object won't be accessed from multiple threads in the same time, thus avoiding adding synchronization code in the object implementation.
You can grab the first parameter of GetToSTA (0x00192888 in this case), dump the contents of the memory at this address (dc 0x00192888). In the result, skip the first 2 DWORD : next DWORD should be the target process ID and next one the target thread ID. This target thread is likely to be already blocked in another operation (refer to http://blogs.msdn.com/b/tess/archive/2008/06/12/asp-net-case-study-deadlock-waiting-in-gettosta.aspx if you need a real life example).

Related

MessageBox API causes access violation and crashes when MB_ICONWARNING is used in combination of MB_OK

i have a legacy MFC application built using VS2005, i migrated it to VS2015, on Windows-10 the application works fine, but when testing on Windows-7, the application crashes whenever it has show a Message box, i found that Application does not crash if i remove the ICONWARNING, even tired with other flags which has icon like MB_ICONERROR, i see crash with this also.
The module is a DLL and not an exe.
MessageBox(NULL,_T("Something"),_T("Some title"),MB_ICONWARNING|MB_OK); //crashes
MessageBox(NULL,_T("Something"),_T("Some title"),MB_OK); //No Crash
Stack trace from the memory dump.
003ce974 7789fb56 00000000 00000000 776f6a2c ntdll!RtlpWaitOnCriticalSection+0xbd
003ce99c 748a5ea6 749cc618 0060e248 0060e240 ntdll!RtlEnterCriticalSection+0x150
003ce9b0 748a6000 0060e248 00020021 003ceaac comctl32!CImageList::_Destroy+0x51
003ce9cc 748a61e7 00000030 00000030 00020021 comctl32!CImageList::_Initialize+0x1b
003ce9f4 748da1fc 0060e260 00000030 00000030 comctl32!CImageList::Initialize+0x30
003cea38 748c8239 00a10253 00000028 00000028 comctl32!CreateSmallerIcon+0x9f
003cea68 7490f79c 02840001 00000054 00000028 comctl32!LoadIconWithScaleDown+0x109
003ceab4 74887fb2 0060a352 00000000 00000081 comctl32!CStatic::LoadImageW+0x10f
003ceb2c 7489780c 0005034e 00000001 00000000 comctl32!CStatic::WndProc+0x1bd
003ceb50 770086ef 0005034e 00000001 00000000 comctl32!CStatic::s_WndProc+0x8b
003ceb7c 770079cc 748977cd 0005034e 00000001 user32!InternalCallWinProc+0x23
003cebf4 770070f4 005a334c 748977cd 0005034e user32!UserCallWinProcCheckWow+0xe0
003cec50 77000b5f 00c79278 00000001 00000000 user32!DispatchClientMessage+0xda
003cec80 778b642e 003cec98 00000060 003cf39c user32!__fnINLPCREATESTRUCT+0x8b
003cecf4 77000d69 77000cfd 00000004 0000c019 ntdll!KiUserCallbackDispatcher+0x2e
003cecf8 77000cfd 00000004 0000c019 003ced48 user32!NtUserCreateWindowEx+0xc
003cef9c 76ff9a8a 00000004 0000c019 003ceff8 user32!VerNtUserCreateWindowEx+0x1a3
003cf078 77025500 76ff0000 00090346 00000000 user32!InternalCreateDialog+0xa4a
003cf0a8 7704e135 76ff0000 0060a2e0 00000000 user32!InternalDialogBox+0xa7
003cf14c 7704e6b9 00000030 68fdf948 00000000 user32!SoftModalMessageBox+0x68a
003cf29c 7704e7ec 003cf2a8 00000028 00000000 user32!MessageBoxWorker+0x2ca
003cf304 7704ea68 00000000 00607c80 00607de0 user32!MessageBoxTimeoutW+0x7f
003cf324 7704eb04 00000000 00607c80 00607de0 user32!MessageBoxExW+0x1b
003cf340 68f31dbf 00000000 00607c80 00607de0 user32!MessageBoxW+0x45
MODULE_NAME: comctl32
IMAGE_NAME: comctl32.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bd976
STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~0s ; .ecxr ; kb
FAILURE_BUCKET_ID: NULL_CLASS_PTR_WRITE_c0000005_comctl32.dll!CImageList::_Destroy
BUCKET_ID: APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE_comctl32!CImageList::_Destroy+51
FAILURE_EXCEPTION_CODE: c0000005
FAILURE_IMAGE_NAME: comctl32.dll
BUCKET_ID_IMAGE_STR: comctl32.dll
FAILURE_MODULE_NAME: comctl32
BUCKET_ID_MODULE_STR: comctl32
FAILURE_FUNCTION_NAME: CImageList::_Destroy
BUCKET_ID_FUNCTION_STR: CImageList::_Destroy
BUCKET_ID_OFFSET: 51
BUCKET_ID_MODTIMEDATESTAMP: 4a5bd976
BUCKET_ID_MODCHECKSUM: 1a1908
BUCKET_ID_MODVER_STR: 6.10.7600.16385
BUCKET_ID_PREFIX_STR: APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE_
FAILURE_PROBLEM_CLASS: APPLICATION_FAULT
FAILURE_SYMBOL_NAME: comctl32.dll!CImageList::_Destroy
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/ABT.exe/2.9.13.7/6110c135/ntdll.dll/6.1.7600.16385/4a5bdadb/c0000005/0002fc47.htm?Retriage=1
TARGET_TIME: 2021-08-10T10:52:43.000Z
OSBUILD: 7600
OSSERVICEPACK: 16385
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
OSPLATFORM_TYPE: x86
OSNAME: Windows 7
OSEDITION: Windows 7 WinNt SingleUserTS
USER_LCID: 0
OSBUILD_TIMESTAMP: 2009-07-14 06:39:01
BUILDDATESTAMP_STR: 090713-1255
BUILDLAB_STR: win7_rtm
BUILDOSVER_STR: 6.1.7600.16385
ANALYSIS_SESSION_ELAPSED_TIME: f8b
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:null_class_ptr_write_c0000005_comctl32.dll!cimagelist::_destroy
FAILURE_ID_HASH: {b3bc3c2c-d915-6f2d-661c-984cc3a945f1}
Thank you for looking to this, appreciate any inputs or suggestions.

How to read a Windows 10 BSOD mini dump analysis

I'm hoping someone here can help.
I have a new Windows 10 machine (all parts by EVGA).
I get random BSOD, so I've grabbed a mini dump, installed the SDK and looked into it. I just don't understand what it is reporting.
Can someone point me in the direction of a guide, or decode this mini dump.
Note : Each dump looks very similar. e.g. almost the same report from 'irp'
Here is the dump....
Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\033016-4718-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 10586 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10586.162.amd64fre.th2_release_sec.160223-1728
Machine Name:
Kernel base = 0xfffff8018d674000 PsLoadedModuleList = 0xfffff8018d952cd0
Debug session time: Wed Mar 30 18:15:33.639 2016 (UTC + 1:00)
System Uptime: 0 days 2:47:26.264
Loading Kernel Symbols
.
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
..............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.............
*
Bugcheck Analysis *
*
Use !analyze -v to get detailed debugging information.
BugCheck 9F, {3, ffffe000935ea880, fffff8018f25a890, ffffe00092718bd0}
Probably caused by : ACPI.sys
Followup: MachineOwner
0: kd> !analyze -v
*
Bugcheck Analysis *
*
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffe000935ea880, Physical Device Object of the stack
Arg3: fffff8018f25a890, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffe00092718bd0, The blocked IRP
Debugging Details:
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING: 10586.162.amd64fre.th2_release_sec.160223-1728
SYSTEM_MANUFACTURER: EVGA INTERNATIONAL CO.,LTD
SYSTEM_PRODUCT_NAME: Default string
SYSTEM_SKU: Default string
SYSTEM_VERSION: Default string
BIOS_VENDOR: American Megatrends Inc.
BIOS_VERSION: 1.07
BIOS_DATE: 01/04/2016
BASEBOARD_MANUFACTURER: EVGA INTERNATIONAL CO.,LTD
BASEBOARD_PRODUCT: 111-SS-E172
BASEBOARD_VERSION: 1.0
DUMP_TYPE: 2
DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump
BUGCHECK_P1: 3
BUGCHECK_P2: ffffe000935ea880
BUGCHECK_P3: fffff8018f25a890
BUGCHECK_P4: ffffe00092718bd0
DRVPOWERSTATE_SUBCODE: 3
IMAGE_NAME: ACPI.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 56cbf9c9
MODULE_NAME: ACPI
FAULTING_MODULE: fffff800d5de0000 ACPI
CPU_COUNT: 8
CPU_MHZ: d50
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 5e
CPU_STEPPING: 3
CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: 33'00000000 (cache) 33'00000000 (init)
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x9F
PROCESS_NAME: System
CURRENT_IRQL: 2
ANALYSIS_SESSION_HOST: Q-PC
ANALYSIS_SESSION_TIME: 03-30-2016 20:04:47.0460
ANALYSIS_VERSION: 10.0.10586.567 x86fre
STACK_TEXT:
fffff8018f25a858 fffff8018d854e42 : 000000000000009f 0000000000000003 ffffe000935ea880 fffff8018f25a890 : nt!KeBugCheckEx
fffff8018f25a860 fffff8018d854d62 : ffffe00096133010 fffff8018f252070 0000000000000000 fffff8018d73e0a6 : nt!PopIrpWatchdogBugcheck+0xde
fffff8018f25a8c0 fffff8018d6e22c6 : ffffe00096133048 fffff8018f25aa10 0000000000000001 0000000000000002 : nt!PopIrpWatchdog+0x32
fffff8018f25a910 fffff8018d7b951a : 0000000000000000 fffff8018d991180 fffff8018da07740 ffffe00096723800 : nt!KiRetireDpcList+0x5f6
fffff8018f25ab60 0000000000000000 : fffff8018f25b000 fffff8018f254000 0000000000000000 0000000000000000 : nt!KiIdleLoop+0x5a
STACK_COMMAND: kb
THREAD_SHA1_HASH_MOD_FUNC: 81a7ba75a791115b4f55c8910c64a260d525502e
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 936d5c51c0ad2157bf4c85af575dd55cea2c0947
THREAD_SHA1_HASH_MOD: f08ac56120cad14894587db086f77ce277bfae84
FOLLOWUP_NAME: MachineOwner
IMAGE_VERSION: 10.0.10586.122
FAILURE_BUCKET_ID: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
BUCKET_ID: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
PRIMARY_PROBLEM_CLASS: 0x9F_3_POWER_DOWN_i8042prt_IMAGE_ACPI.sys
TARGET_TIME: 2016-03-30T17:15:33.000Z
OSBUILD: 10586
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2016-02-24 05:48:00
BUILDDATESTAMP_STR: 160223-1728
BUILDLAB_STR: th2_release_sec
BUILDOSVER_STR: 10.0.10586.162.amd64fre.th2_release_sec.160223-1728
ANALYSIS_SESSION_ELAPSED_TIME: 3d7
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x9f_3_power_down_i8042prt_image_acpi.sys
FAILURE_ID_HASH: {22a3ff34-49ca-8d37-715b-ae023b6cc9fb}
Followup: MachineOwner
0: kd> !irp ffffe00092718bd0
Irp is active with 8 stacks 6 is current (= 0xffffe00092718e08)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
0 0 ffffe000935ea880 00000000 fffff800d6a81ec0-00000000
\Driver\ACPI i8042prt!I8xPowerUpToD0Complete
Args: 00000000 00000000 00000000 00000002
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe00093f936f0 00000000 fffff800d6ab1060-00000000 Success Error Cancel pending
\Driver\i8042prt kbdclass!KeyboardClassPowerComplete
Args: 00051100 00000001 00000001 00000002
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe00093dc95f0 00000000 fffff8018d7840b8-ffffe00096133010 Success Error Cancel pending
\Driver\kbdclass nt!PopRequestCompletion
Args: 00051100 00000001 00000001 00000002
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-ffffe00096133010
Args: 00000000 00000000 00000000 00000000
I'm also adding a BlueScreen screen shot, incase that helps.
Now adding output from some extra commands after Martins comments...
0: kd> !devstack ffffe000935ea880
!DevObj !DrvObj !DevExt ObjectName
ffffe00093dc95f0 \Driver\kbdclass ffffe00093dc9740 InfoMask field not found for _OBJECT_HEADER at ffffe00093dc95c0
ffffe00093f936f0 \Driver\i8042prt ffffe00093f93840 InfoMask field not found for _OBJECT_HEADER at ffffe00093f936c0
> ffffe000935ea880 \Driver\ACPI ffffe000923fa8d0 Cannot read info offset from nt!ObpInfoMaskToOffset
!DevNode ffffe000935d6af0 :
DeviceInst is "ACPI\PNP0303\0"
ServiceName is "i8042prt"
!process 0 7
**** NT ACTIVE PROCESS DUMP ****
GetPointerFromAddress: unable to read from fffff8018d9f3200
Error in reading nt!_EPROCESS at 0000000000000000
0: kd> !poaction
PopAction: fffff8018d94efe0
State..........: 0 - Idle
Updates........: 0
Action.........: None
Lightest State.: Unspecified
Flags..........: 10000003 QueryApps|UIAllowed
Irp minor......: ??
System State...: Unspecified
Hiber Context..: 0000000000000000
Allocated power irps (PopIrpList - fffff8018d94f4f0)
IRP: ffffe00092718bd0 (set/D0,), PDO: ffffe000935ea880, CURRENT: ffffe00093f936f0
IRP: ffffe000971aa990
Irp worker threads (PopIrpThreadList - fffff8018d94e100)
THREAD: ffffe00091515040 (static)
THREAD: ffffe00091501800 (static)
Error resolving nt!_POP_CURRENT_BROADCAST...
Summary: Error was caused by my 10 year old Razor mouse with Windows 10.
The driver when entering power save state was freaking out and causing the blue screen.
I purchased a new mouse, removed the driver & 2 months in no more BSOD.
I usually use BlueScreenView by Nirsoft. It will get you a list of last BSOD and will show a nice view of the components. "Normally" the first mentioned component could be the reason.
Not sure, if you are looking for a solution on a specific problem or the minidump usage in general.
Some driver got problems with power state change. Make sure, you have the current Drivers installed.

Need help to understand kernel debugging error

Need help to understand kernel debugging error.
When I put my driver for Whck test for windows 8(32/64 bit), it fails CHAOS in RUN TEST.
So I did kernel debugging and got following debug message.But I don't understand where is the error in my ioctl.c file.Same driver has cleared the test for windows 7 32 bit.
*** Fatal System Error: 0x0000000a
(0x00000031,0x00000002,0x00000000,0x81CB1194)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
nt!RtlpBreakWithStatusInstruction:
818d6ca4 cc int 3
2: kd> !analyze -v
Connected to Windows 8 9200 x86 compatible target at (Tue May 27 11:56:02.788 2014 (UTC - 7:00)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
.............................................
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
...................
........................
Loading User Symbols
Loading unloaded module list
.........Unable to enumerate user-mode unloaded modules, Win32 error 0n30
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000031, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 81cb1194, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: 00000031
CURRENT_IRQL: 2
FAULTING_IP:
nt!VerifierKeSynchronizeExecution+26
81cb1194 0fb64631 movzx eax,byte ptr [esi+31h]
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: AV
PROCESS_NAME: System
TRAP_FRAME: b74a594c -- (.trap 0xffffffffb74a594c)
ErrCode = 00000000
eax=9132b7d8 ebx=b23f4a38 ecx=b74a59d8 edx=9184c628 esi=00000000 edi=9184c570
eip=81cb1194 esp=b74a59c0 ebp=b74a59c4 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!VerifierKeSynchronizeExecution+0x26:
81cb1194 0fb64631 movzx eax,byte ptr [esi+31h] ds:0023:00000031=??
Resetting default scope
LAST_CONTROL_TRANSFER: from 818fefc7 to 818d6ca4
STACK_TEXT:
b74a54e4 818fefc7 00000003 d565b8ac 00000031 nt!RtlpBreakWithStatusInstruction
b74a5534 818fe861 00000003 8286a340 b74a5934 nt!KiBugCheckDebugBreak+0x1c
b74a5908 818d56a6 0000000a 00000031 00000002 nt!KeBugCheck2+0x655
b74a592c 8194ed9b 0000000a 00000031 00000002 nt!KiBugCheck2+0xc6
b74a592c 81cb1194 0000000a 00000031 00000002 nt!KiTrap0E+0x1b3
b74a59c4 9132b7d8 00000000 9132ef20 b74a59d8 nt!VerifierKeSynchronizeExecution+0x26
b74a5a30 81ca1f9b 9184c570 adcf4f00 adcf4f00 OxSer!OxserInternalIoControl+0x328 [c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c # 2570]
b74a5a50 81830066 81cb97fd adcf4fd4 adcf4ff8 nt!IovCallDriver+0x2e3
b74a5a64 81cb97fd b74a5a8c 81cb98f4 9184c570 nt!IofCallDriver+0x73
b74a5a6c 81cb98f4 9184c570 adcf4f00 ace85a30 nt!ViFilterIoCallDriver+0x10
b74a5a8c 81ca1f9b ace85ae8 adcf4f00 81ca27c1 nt!ViFilterDispatchGeneric+0x5e
b74a5aac 81830066 8f7eab44 ace85a30 8ad0c710 nt!IovCallDriver+0x2e3
b74a5ac0 8f7eab44 b74a5b0c b74a5b0c b74a5c14 nt!IofCallDriver+0x73
b74a5ad0 8f7ea625 001b0010 00000001 ace85a30 serenum!Serenum_IoSyncIoctlEx+0x48
b74a5c14 8f7e537d b7196ed8 b74a5c33 b7a84340 serenum!Serenum_ReenumerateDevices+0x259
b74a5c34 81866b1b b7196ed8 d565b1e8 00000000 serenum!SerenumEnumThread+0x57
b74a5c70 81950579 8f7e5326 8ad0c710 00000000 nt!PspSystemThreadStartup+0x4a
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
STACK_COMMAND: kb
FOLLOWUP_IP:
OxSer!OxserInternalIoControl+328 [c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c # 2570]
9132b7d8 8b4dcc mov ecx,dword ptr [ebp-34h]
FAULTING_SOURCE_LINE: c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c
FAULTING_SOURCE_FILE: c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c
FAULTING_SOURCE_LINE_NUMBER: 2570
FAULTING_SOURCE_CODE:
No source found for 'c:\users\admin\desktop\trunk\uart_v7.0\source\uart\driver\wdm\ioctl.c'
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: OxSer!OxserInternalIoControl+328
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: OxSer
IMAGE_NAME: OxSer.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 53802c0f
BUCKET_ID_FUNC_OFFSET: 328
FAILURE_BUCKET_ID: AV_VRF_OxSer!OxserInternalIoControl
BUCKET_ID: AV_VRF_OxSer!OxserInternalIoControl
Followup: MachineOwner
---------
The routine that crashed was actually in the OS verifier. This is a set of function that perform additional validation on driver calls when driver development is performed in order to find driver bugs.
You are probably not crashing on Win7 because either the verifier is not turned on or the verifier was not detecting this problem in Win7. While your code is not crashing, it is probably still doing something that will cause OS instability at some point.
You should view this as Win8 helping you identify a real bug much more easily, rather than under weird circumstances after you shipped your driver.

Analyzing Outlook hang dump in my VSTO addin - Redemption

my problem is related and very similar to this one:
Analyzing Outlook HANG dump (with GoogleCalendarSync add-in installed)
The problem is, my addin seems to hang sometimes when a new mail arrives (at least that what it seems to happen, also based on the stack info below. The application log tells me something like "Cross Thread Deadlock". My addin is a managed VSTO addin.
Here is the hang dump analsis:
FAULTING_IP:
+0
00000000 ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000007 (Wake debugger)
ExceptionFlags: 00000000
NumberParameters: 0
CONTEXT: 00000000 -- (.cxr 0x0;r)
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00bd7028 edi=00000000
eip=77bff8d1 esp=0044e44c ebp=0044e4b0 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll!ZwWaitForSingleObject+0x15:
77bff8d1 83c404 add esp,4
BUGCHECK_STR: HANG
DEFAULT_BUCKET_ID: APPLICATION_HANG
PROCESS_NAME: OUTLOOK.EXE
ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: outlook.exe
ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
MANAGED_STACK:
(TransitionMU)
0044EA3C 06019026 UNKNOWN!DomainBoundILStubClass.IL_STUB_CLRtoCOM(System.String, System.Object, System.Object)+0x1d6
(TransitionUM)
(TransitionMU)
0044EC2C 06018DD8 UNKNOWN!yasoonBase.Controller.Outlook.OutlookPersistenceSynchronizer.userStore_OnNewMail(System.String)+0x58
(TransitionUM)
(TransitionMU)
0044F01C 642F371D mscorlib_ni!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(System.Object, System.Object[], System.Object[])+0x5d
0044F040 642EF8FA mscorlib_ni!System.Delegate.DynamicInvokeImpl(System.Object[])+0x76
0044F054 64AE1753 mscorlib_ni!System.Runtime.InteropServices.ComEventsMethod+DelegateWrapper.Invoke(System.Object[])+0x8f
0044F068 64AE08BB mscorlib_ni!System.Runtime.InteropServices.ComEventsMethod.Invoke(System.Object[])+0x2f
0044F080 64AE0194 mscorlib_ni!System.Runtime.InteropServices.ComEventsSink.System.Runtime.InteropServices.NativeMethods.IDispatch.Invoke(Int32, System.Guid ByRef, Int32, System.Runtime.InteropServices.ComTypes.INVOKEKIND, System.Runtime.InteropServices.ComTypes.DISPPARAMS ByRef, IntPtr, IntPtr, IntPtr)+0x168
0044F0C8 64951D11 mscorlib_ni!DomainNeutralILStubClass.IL_STUB_COMtoCLR(Int32, IntPtr, Int32, Int32, IntPtr, Int32, Int32, Int32)+0x29
(TransitionUM)
MANAGED_STACK_COMMAND: _EFN_StackTrace
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- --------------------------
0 1d24.16e4 Event -->
54 1d24.1e20 SendMessage
WAIT_CHAIN_COMMAND: ~0s;k;;~54s;k;;
BLOCKING_THREAD: 00001e20
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG
LAST_CONTROL_TRANSFER: from 76e0216b to 76df72b9
FAULTING_THREAD: 00000036
STACK_TEXT:
2a9bbd48 76e0216b 003e0fd8 0000c382 00000001 user32!NtUserMessageCall+0x15
2a9bbd88 76df96c5 022c5d90 00000000 25ecd700 user32!SendMessageWorker+0x3c6
2a9bbdac 25ecdaa0 003e0fd8 0000c382 00000001 user32!SendMessageW+0x7f
WARNING: Stack unwind information not available. Following frames may be wrong.
2a9bbdcc 18314b60 1d133da0 00000001 2a9bbe10 redemption!InitExtensionLibrary+0x4b31c
2a9bbdec 1832467f 00bd6ff0 00000001 2a9bbe10 PSTPRX32!PRXServiceEntry+0xdbaf
2a9bbe6c 18324485 2a9bc820 29e66080 00000005 PSTPRX32!PRXServiceEntry+0x1d6ce
2a9bbeb0 18323b3a 2a9bc820 e4c3e839 00000001 PSTPRX32!PRXServiceEntry+0x1d4d4
2a9bbee0 18325c83 2a9bc7e4 2a9bc7e4 00000000 PSTPRX32!PRXServiceEntry+0x1cb89
2a9bbef8 1831a506 00000000 2a9bc7e4 00000000 PSTPRX32!PRXServiceEntry+0x1ecd2
2a9bc740 1289e3c8 29e64ab4 2a9bc7e4 00000000 PSTPRX32!PRXServiceEntry+0x13555
2a9bc75c 1289a277 29e64ab4 2a9bc7e4 26bc23b8 OUTLMIME!CloseAllSockets+0xea20
2a9bc854 128999e7 2a9bc93c 00000fff 210428ad OUTLMIME!CloseAllSockets+0xa8cf
2a9bc8c0 12898d24 2a9bc93c 210428a2 2a9bc9ac OUTLMIME!CloseAllSockets+0xa03f
2a9bc8e8 1289c957 2a9bc93c 210428a2 2a9bc980 OUTLMIME!CloseAllSockets+0x937c
2a9bc98c 1289cc65 1802d2b8 00000003 2a9bc9ac OUTLMIME!CloseAllSockets+0xcfaf
2a9bcdbc 12896de5 00000005 26bc23c0 26e38f18 OUTLMIME!CloseAllSockets+0xd2bd
2a9bd254 12890bb7 00000005 00000005 00000003 OUTLMIME!CloseAllSockets+0x743d
2a9bd278 1289150b 00000005 00000003 26e38f18 OUTLMIME!CloseAllSockets+0x120f
2a9bd2b4 1289128c 00000000 1808dcc0 00000000 OUTLMIME!CloseAllSockets+0x1b63
2a9bf2d8 1288ffd6 00000000 00000401 26e38690 OUTLMIME!CloseAllSockets+0x18e4
2a9bf6fc 1289201a 00000401 00002bc4 00000001 OUTLMIME!CloseAllSockets+0x62e
2a9bf718 76df62fa 00580ad4 00000401 00002bc4 OUTLMIME!CloseAllSockets+0x2672
2a9bf744 76df6d3a 12891fd1 00580ad4 00000401 user32!InternalCallWinProc+0x23
2a9bf7bc 76df77c4 00000000 12891fd1 00580ad4 user32!UserCallWinProcCheckWow+0x109
2a9bf81c 76df7bca 12891fd1 00000001 2a9bfc8c user32!DispatchMessageWorker+0x3bc
2a9bf82c 1831beda 2a9bf844 00000001 29eb58c8 user32!DispatchMessageA+0xf
2a9bfc8c 0f598abc 29e64aa8 29eb58c8 1922eb58 PSTPRX32!PRXServiceEntry+0x14f29
2a9bfcb8 0f598a08 29eb5b80 1922eb58 26b13240 OLMAPI32!MemGetMalloc+0xbed
2a9bfcd4 655b5155 1922ebc8 26b13240 655ac3bb OLMAPI32!MemGetMalloc+0xb39
2a9bfd04 655ab3a2 2a9bfd74 2a9bfd58 00598790 MSO!Ordinal5372+0x66
2a9bfd1c 655a817f 2a9bfd74 00000000 00598790 MSO!Ordinal4578+0x1bc
2a9bfd50 655a6e0d 00000000 655a6e0d 2a9bfd74 MSO!Ordinal630+0x18ed
2a9bfda4 756a336a 00598790 2a9bfdf0 77c19f72 MSO!Ordinal630+0x57b
2a9bfdb0 77c19f72 00598790 5671c62f 00000000 kernel32!BaseThreadInitThunk+0xe
2a9bfdf0 77c19f45 655a6db4 00598790 ffffffff ntdll!__RtlUserThreadStart+0x70
2a9bfe08 00000000 655a6db4 00598790 00000000 ntdll!_RtlUserThreadStart+0x1b
FOLLOWUP_IP:
redemption!InitExtensionLibrary+4b31c
25ecdaa0 c3 ret
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: redemption!InitExtensionLibrary+4b31c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: redemption
IMAGE_NAME: redemption.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 52791e66
STACK_COMMAND: ~54s ; kb
BUCKET_ID: HANG_redemption!InitExtensionLibrary+4b31c
FAILURE_BUCKET_ID: APPLICATION_HANG_cfffffff_redemption.dll!InitExtensionLibrary
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:application_hang_cfffffff_redemption.dll!initextensionlibrary
FAILURE_ID_HASH: {c9d67d3f-8e85-921b-11e8-c7a8dfc70981}
Followup: MachineOwner
The OnNewMail event handler does not very much imho:
void userStore_OnNewMail(string entryID)
{
//Get mail from store & raise event
RDOMail mail = mapiSession.GetMessageFromID(entryID, this.storeEntryId);
var args = new MailEventArguments(mail, ChangeType.New);
this.eventPublisher.RaiseEvent(new MailEvent(args));
}
One thing I noticed - This seems to happen especially on non-default Outlook stores, though this event is not expected to be fired on non-default stores anyway...
What I'm trying to understand, what is the other thread which blocks this one, is there any possibility to get that information?
Any feedback would be highly appreciated ...
Thanks!

Crash when waiting for WorkerThread in Destructor

I have a problem with Virtual Treeview Destructor, which stops the WorkerThread while it is still running.
Code:
destructor TBaseVirtualTree.Destroy;
begin
Exclude(FOptions.FMiscOptions, toReadOnly);
ReleaseThreadReference(Self);
and the code for ReleaseThreadReference:
procedure ReleaseThreadReference(Tree: TBaseVirtualTree);
begin
if Assigned(WorkerThread) then
begin
Dec(WorkerThread.FRefCount);
// Make sure there is no reference remaining to the releasing tree.
Tree.InterruptValidation;
if WorkerThread.FRefCount = 0 then
begin
with WorkerThread do
begin
Terminate;
SetEvent(WorkEvent);
end;
FreeAndNil(WorkerThread);
CloseHandle(WorkEvent);
end;
end;
end;
And output from WinDbg:
FAULTING_IP:
vcl120!Forms.TGlassFrame.FrameExtended+3
501f0b57 807b0800 cmp byte ptr [ebx+8],0
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 501f0b57 (vcl120!Forms.TGlassFrame.FrameExtended+0x00000003)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000008
Attempt to read from address 00000008
PROCESS_NAME: MyProcess.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 00000008
READ_ADDRESS: 00000008
FOLLOWUP_IP:
vcl120!Forms.TGlassFrame.FrameExtended+0
501f0b54 53 push ebx
FAULTING_THREAD: 00000894
ADDITIONAL_DEBUG_TEXT: Followup set via attribute from Frame 0 on thread 894
BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_WINDOW_HOOK
PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_DEREFERENCE
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
LAST_CONTROL_TRANSFER: from 501c565d to 501f0b57
00d7eca4 501c565d 00d7efb0 028408b9 00d7ee74 vcl120!Forms.TGlassFrame.FrameExtended+0x3
00d7edd0 501c9cec 00d7ee74 01a58e10 77c2c3ce vcl120!Controls.TControl.WndProc+0x2d5
00d7ee10 501e5a59 00d7efb0 028408b9 02190e80 vcl120!Controls.TWinControl.WndProc+0x518
00d7ee3c 501c9403 00d7ee50 50007cb0 00d7ee6c vcl120!Forms.TCustomForm.WndProc+0x599
00d7ee6c 500591de 00000046 00000000 00d7efb0 vcl120!Controls.TWinControl.MainWndProc+0x2f
00d7ee84 77d48709 002b00ee 00000046 00000000 rtl120!Classes.StdWndProc+0x16
00d7eeb0 77d4d297 028408b9 002b00ee 00000046 user32!InternalCallWinProc+0x28
00d7ef18 77d4b368 00000000 028408b9 002b00ee user32!UserCallWinProcCheckWow+0xea
00d7ef6c 77d4d1da 01c9c880 00000046 00000000 user32!DispatchClientMessage+0xa3
00d7ef94 7c90eae3 00d7efa4 00000030 01c9c880 user32!__fnINOUTLPWINDOWPOS+0x27
00d7efac 002b00ee 00000000 00000000 00000000 ntdll!KiUserCallbackDispatcher+0x13
00d7efe8 501e6a2b 002b00ee 00000000 00d7f1cc MainControls!TUJournalIntf.ImportFunFile+0x33a
00d7f020 501e88cc 02190e80 00d7f158 501c565d vcl120!Forms.TCustomForm.SetMenu+0x197
00d7f02c 501c565d 00d7f35c 028408b9 00d7f1fc vcl120!Forms.TCustomForm.WMNCCreate+0x20
00d7f158 501c9cec 00d7f1fc 00d7f1a4 501c9cec vcl120!Controls.TControl.WndProc+0x2d5
00d7f198 501e5a59 00d7f35c 028408b9 02190e80 vcl120!Controls.TWinControl.WndProc+0x518
00d7f1c4 501c9403 00d7f1d8 501c941b 00d7f1f4 vcl120!Forms.TCustomForm.WndProc+0x599
00d7f1f4 500591de 00000081 00000000 00d7f35c vcl120!Controls.TWinControl.MainWndProc+0x2f
00d7f20c 77d48709 002b00ee 00000081 00000000 rtl120!Classes.StdWndProc+0x16
00d7f238 77d4d297 028408b9 002b00ee 00000081 user32!InternalCallWinProc+0x28
00d7f2a0 77d4b368 00000000 028408b9 002b00ee user32!UserCallWinProcCheckWow+0xea
00d7f2f4 77d4e840 01c9c880 00000081 00000000 user32!DispatchClientMessage+0xa3
00d7f324 7c90eae3 00d7f334 00000060 00000060 user32!__fnINLPCREATESTRUCT+0x8b
00d7f390 77d517eb 77d517b1 00050000 00d7f8b8 ntdll!KiUserCallbackDispatcher+0x13
00d7f834 77d518a4 00050000 00d7f8b8 00d7f8cc user32!NtUserCreateWindowEx+0xc
00d7f8e0 77d51b08 00050000 00d7fa04 00d7f8cc user32!_CreateWindowEx+0x1ed
00d7f91c 50122dd0 00050000 00d7fa04 0b3413bc user32!CreateWindowExW+0x33
00d7f964 501c8b29 00000000 50120000 00000000 vcl120!Windows.CreateWindowEx+0x44
00d7faa8 501c8a47 00d7fc80 501c8ae7 00d7fbc4 vcl120!Controls.TWinControl.CreateWindowHandle+0x35
00d7fbc4 501e3682 02190e80 501e7787 00d7f9cc vcl120!Controls.TWinControl.CreateWnd+0x13f
00d7fc18 77d4d86f 000100a8 00d7fc68 00d7fcf8 vcl120!Forms.TScrollingWinControl.CreateWnd+0xa
00d7fc38 77d4d94b 00000000 00000000 501ed470 user32!InternalEnumWindows+0x5a
00d7fc58 501ed556 501ed470 00d7fc68 00450242 user32!EnumWindows+0x16
00d7fce0 500591de 0000001c 00000000 00000454 vcl120!Forms.TApplication.DoNormalizeTopMosts+0x32
00d7fcf8 77d48709 00450242 0000001c 00000000 rtl120!Classes.StdWndProc+0x16
00d7fd24 77d487eb 02840fe2 00450242 0000001c user32!InternalCallWinProc+0x28
00d7fd8c 77d4b368 00000000 02840fe2 00450242 user32!UserCallWinProcCheckWow+0x150
00d7fde0 77d4b3b4 01c8f058 0000001c 00000000 user32!DispatchClientMessage+0xa3
00d7fe08 7c90eae3 00d7fe18 00000018 01c8f058 user32!__fnDWORD+0x24
00d7fe2c 77d493c6 77d49385 00d7feac 00000000 ntdll!KiUserCallbackDispatcher+0x13
00d7fe58 77d493df 00d7feac 00000000 00000000 user32!NtUserPeekMessage+0xc
00d7fe84 500576a4 00d7feac 00000000 00000000 user32!PeekMessageW+0xbc
00d7fee8 50006c37 5002b6a9 01783c94 00d7ff08 rtl120!Classes.TThread.WaitFor+0x5c
00d7fef8 0178fc99 00000003 021d5800 021d5830 rtl120!System.TObject.Free+0xb
00d7ff08 501c7240 02190e80 021d5830 021d5830 VirtualTreesR!VirtualTrees.TBaseVirtualTree.Destroy+0x21
00d7ff1c 501cef46 00000002 00000000 501c7240 vcl120!Controls.TWinControl.Destroy+0x90
00d7ff28 501c7240 00d7ff64 02190e80 02190e80 vcl120!Controls.TCustomControl.Destroy+0x22
00000000 00000000 00000000 00000000 00000000 vcl120!Controls.TWinControl.Destroy+0x90
SYMBOL_NAME: vcl120!Forms.TGlassFrame.FrameExtended+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: vcl120
IMAGE_NAME: vcl120.bpl
DEBUG_FLR_IMAGE_TIMESTAMP: 4a0b8b7f
STACK_COMMAND: .ecxr ; ~~[894] ; .frame 0 ; ~0s; .ecxr ; kb
FAILURE_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE_c0000005_vcl120.bpl!Forms.TGlassFrame.FrameExtended
BUCKET_ID: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_WINDOW_HOOK_vcl120!Forms.TGlassFrame.FrameExtended+0
If you look at this line in callstack "0000001c 00000000 rtl120!Classes.StdWndProc+0x16", you can see that application processed WM_ACTIVATEAPP(0x1C) message and called "DoNormalizeTopMosts" (I think this leads to create main form again). I found in our project DevExpress6 with "dxBarWndProcHook", maybe this is a problem, but I'm not sure. I have no idea why this is happen - function TThread.WaitFor processed message which leads to recreate form.
Please, could anyone help me to solve this? Thank you in advance!

Resources