WB 8.01 multiple resource leaks on Win8-x64 Ent

By on September 11, 2013 1:57:49 AM from Stardock Forums Stardock Forums

mabreedlove

Join Date 08/2013
+2

WindowBlinds v8.0, beta v8.01, and v8.01 suffer from a few memory leaks with varying consequences.

 

System Info:


Windows 8 Enterprise x64

Intel Core i7 920 @ 2.67GHz

Dual NVIDIA GeForce GTX550-TI (Dual monitors powered seperately)

24GB DDR3 RAM

 

Issues:

 

1.  Likely video memory leak results in an eventual crash of explorer.exe or DWM failure resulting in a black screen and subsequent forced logout.

 

This one seems to pop up the longer the system runs until explorer.exe starts failing to repaint parts of the taskbar, explorer windows, etc.  The result is a crash of explorer.exe and possibly DWM failure which causes a black screen with mouse pointer and eventual forced logout, closing all applications in the process.  The black screen doesn't react to Ctrl+Alt+Delete or any other hotkeys.  The problem occurs regardless of whether using the default Windows theme or a custom theme.  Disabling WB start-up prevents the issue from occuring while Start8 and ModernMix don't seem to be related.

 

Relevant Events:

 

Microsoft-Windows-Diagnostics-Performance - Event ID 500

Scenario : The Desktop Window Manager responsiveness has degraded.Microsoft-Windows-Diagnostics-Performance
The Desktop Window Manager is experiencing heavy resource contention.

 

Microsoft-Windows-Diagnostics-Performance - Event ID 501

The Desktop Window Manager is experiencing heavy resource contention.
Reason : Graphics subsystem resources are over-utilized.
Diagnosis : A consistent degradation in frame rate for the Desktop Window Manager was observed over a period of time.

 

System doesn't report any issues in the Fault Tolerant Heap, Resource Exhaustion Detector, Resource Leak Diagnostic, etc.

 

2.  wb8config.exe has a resource leak that manifests itself after changing the textures of a skin multiple times under Edit Effect.  The result is either a crash of the process, all texture selection thumbnails showing the same texture, or window painting errors.  The process crashes when clicking the close button but the rendering issues can appear prior to clicking close.  Relevant events and analysis listed below.  Memory dump available if requested.

 

Relevant Events:

Faulting application name: wb8Config.exe, version: 8.0.1.0, time stamp: 0x51e7f0cb
Faulting module name: wb8Config.exe, version: 8.0.1.0, time stamp: 0x51e7f0cb
Exception code: 0xc000041d
Fault offset: 0x0004d50d
Faulting process id: 0x33b8
Faulting application start time: 0x01ceaea6dcc1c29d
Faulting application path: C:\Program Files (x86)\Stardock\WindowBlinds\wb8Config.exe
Faulting module path: C:\Program Files (x86)\Stardock\WindowBlinds\wb8Config.exe
Faulting package full name:
Faulting package-relative application ID:

 

Wingdbg First Chance Exception Analysis:

 

FAULTING_IP:
SevenConfig+4d50d
00c0d50d f00fc111 lock xadd dword ptr [ecx],edx

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000c0d50d (SevenConfig+0x000000000004d50d)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000001
Parameter[1]: 00000000000002f0
Attempt to write to address 00000000000002f0

FAULTING_THREAD: 0000000000007950
PROCESS_NAME: SevenConfig.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: 0000000000000001
EXCEPTION_PARAMETER2: 00000000000002f0
WRITE_ADDRESS: 00000000000002f0

FOLLOWUP_IP:
SevenConfig+4d50d
00c0d50d f00fc111 lock xadd dword ptr [ecx],edx

NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: sevenconfig.exe
BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_ZEROED_STACK
PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_WRITE
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_WRITE
LAST_CONTROL_TRANSFER: from 0000000000c33bee to 0000000000c0d50d

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
010578fc 00c33bee 01064984 00000014 00000234 SevenConfig+0x4d50d
01057930 00beeaae 2663113b 0000c57f 074816b0 SevenConfig+0x73bee
01066d04 00c4b475 0000c57f 00231364 00000000 SevenConfig+0x2eaae
01066d78 00c4b504 074816b0 00131228 0000c57f SevenConfig+0x8b475
01066d98 74e977d8 00131228 0000c57f 00231364 SevenConfig+0x8b504
01066dc4 74e978cb 00c4b4ce 00131228 0000c57f USER32!InternalCallWinProc+0x23
01066e40 74e97b6f 00c4b4ce 00c4b4ce 00000000 USER32!UserCallWinProcCheckWow+0x100
01066ea4 74e97c44 01a37b40 00000000 0000c57f USER32!DispatchClientMessage+0x15d
01066ee0 77442c92 01066ef8 00000000 010670c8 USER32!__fnDWORD+0x2b
01066f14 74e9aa46 00131228 0000c57f 00231364 ntdll_77400000!KiUserCallbackDispatcher+0x2e
01066f78 74e9aaa6 01a37b40 00000000 0000c57f USER32!SendMessageWorker+0x76c
01066fa0 00bd441c 00131228 0000c57f 00231364 USER32!SendMessageW+0x8b
01067030 74e977d8 00231364 00000202 00000000 SevenConfig+0x1441c
0106705c 74e978cb 00bd44d0 00231364 00000202 USER32!InternalCallWinProc+0x23
010670d8 74e9899d 00bd44d0 00bd44d0 00000000 USER32!UserCallWinProcCheckWow+0x100
0106714c 74ea5c40 00000000 74e9aa54 073a8020 USER32!DispatchMessageWorker+0x3ef
01067184 00c4e4c5 000517c4 014a7e28 073a8020 USER32!IsDialogMessageW+0x171
01067198 00c48d1d 014a7e28 010671bc 00c5557c SevenConfig+0x8e4c5
010671a4 00c5557c 014a7e28 014a7e28 74ea71cc SevenConfig+0x88d1d
010671bc 00c4aa54 014a7e28 014a7e28 010672d0 SevenConfig+0x9557c
010671d0 00c5c1ef 00071210 014a7e28 014a7df8 SevenConfig+0x8aa54
010671e8 00c5c349 014a7e28 01067200 00c5c23a SevenConfig+0x9c1ef
010671f4 00c5c23a 014a7e28 01067238 00c5c396 SevenConfig+0x9c349
01067200 00c5c396 014a7e28 00000000 010672d0 SevenConfig+0x9c23a
01067238 00c4739e 00000004 26630ebb 00ddf0c8 SevenConfig+0x9c396
01067284 00c12d1c 26708b37 00ddf0c8 00ddf0c8 SevenConfig+0x8739e
0115f708 00d620ec 00000000 00000000 7e66f000 SevenConfig+0x52d1c
0115f71c 00d460fb 00bc0000 00000000 01473640 SevenConfig+0x1a20ec
0115f7ac 76e4850d 7e66f000 0115f7fc 7745bf39 SevenConfig+0x1860fb
0115f7b8 7745bf39 7e66f000 f3044abb 00000000 KERNEL32!BaseThreadInitThunk+0xe
0115f7fc 7745bf0c 00d4614e 7e66f000 ffffffff ntdll_77400000!__RtlUserThreadStart+0x72
0115f814 00000000 00d4614e 7e66f000 00000000 ntdll_77400000!_RtlUserThreadStart+0x1b


SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: sevenconfig+4d50d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: SevenConfig
IMAGE_NAME: wb8Config.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 51e7f0cb
STACK_COMMAND: ~0s ; kb

FAILURE_BUCKET_ID: NULL_CLASS_PTR_WRITE_c0000005_wb8Config.exe!Unknown
BUCKET_ID: APPLICATION_FAULT_NULL_CLASS_PTR_WRITE_ZEROED_STACK_sevenconfig+4d50d

 

As this system is for development, security research, and reverse engineering, I can gather pretty much gather any additional information, dumps, traces, etc.  The first issue is my primary concern since it prevents me from using WB in any capacity.  Whether or not this is relevant, app verifier running with heap checking enabled results in a crash in wblindp2!GetNextFrame+6c62 due to an access violation from NULL_CLASS_PTR_READ.

 

 

 

14 Replies
Search this post
Subscription Options


Reason for Karma (Optional)
Successfully updated karma reason!
September 11, 2013 2:14:18 AM from WinCustomize Forums WinCustomize Forums

mabreedlove .... thanks for the info.  I'm sure Neil will find it helpful ....

Reason for Karma (Optional)
Successfully updated karma reason!
September 11, 2013 6:03:30 AM from Stardock Forums Stardock Forums

If a problem continues with the default theme applied then it is unlikely to be WindowBlinds at fault.  Default theme means turn WindowBlinds off and almost no code is running on a reboot in that state and it should not be allocating any memory or GDI resources.

That's assuming that the theme was the one set when you rebooted as if you had previously run a WB theme in the session then a leak could occur.

If it happens again, could you see if any process in taskmanager appears to have high GDI usage please.

The second issue on the other hand looks more WB like and I will get the addresses checked to see if anything obvious shows up, thanks for the full info on that.

Reason for Karma (Optional)
Successfully updated karma reason!
September 11, 2013 10:57:38 PM from Stardock Forums Stardock Forums

Normally I would agree that it wouldn't be WB that was the cause but after logging back in without rebooting after the DWM failure (essentially the second session), the problem never occurs again and the only module missing from the explorer process is WindowBlinds.  All other modules such as Start8 and ModernMix reinject themselves properly.  This is despite the fact that the WindowBlinds service is still running.  After a reboot, the module appears in explorer.exe as it should.  I find this distinctly odd that the only module not present after the fact and the one that would generally handle the most drawing events is seemingly absent after the fact and the issue never presents itself again until a reboot when the module is present.

I haven't yet rebooted but currently the explorer allocated GPU system memory is sitting @ 61.36mb and GPU dedicated @ 16.56mb.  Most consuming GDI handles right now is the secondary explorer.exe process that handles Explorer windows with 1951 handles which is about what it should be.  I have split the explorer processes up so that the rendering explorer wouldn't crash as a result of a file browser window.  DWM has 724mb dedicated memory with 28 GDI handles currently.  That's the typical usage for what I have open currently which includes Chrome, VLC, and Spotify.

Also, one thing I forgot to mention in my initial report is that after logging in after the initial crash, and opening event viewer, each event had an extra line of text at the bottom stating something to the effect of an invalid reference handle.  This appeared on the bottom of every since event regardless of when it was recorded along with each event not being able to resolve the text for any event ID.  After some time, the extra text and event ID resolution problem disappeared on its own most likely after I ran automatic maintenance but I can't say for certain.  This leads me to believe HANDLEs are being leaked and not necessarily the result of system memory or video memory leakage considering if my 24GB of ram were to ever be filled up then my measly 1GB pagefile wouldn't be enough to prevent a bugcheck and video memory exhaustion would result in a device driver malfunction message rather than what shows up currently.

 

Anyway, I'll reboot and get back to you on the handles.  When I get more free time, I think its probably more beneficial to you if I just set gflags and/or hyper-v debugging to pinpoint the cause.  Problems like this are a true bitch to resolve since they rule out any user-mode debugging tools.  IDA or VS debugging would be so much more helpful.  On the second, it takes very little time to run an instruction or function trace since I can reproduce the problem with 100% consistency if you need me to.  Memory dumps aren't an issue although I'd prefer not to put them up on a public link.  The next time I get an explorer crash dump I'll pass along any info as well.

Reason for Karma (Optional)
Successfully updated karma reason!
Sign Up or Login and this ad disappears!
There are many great features available to you once you register. Sign Up for a free account and browse the forums without ads.
September 11, 2013 11:19:37 PM from WinCustomize Forums WinCustomize Forums

Quoting mabreedlove,
Memory dumps aren't an issue although I'd prefer not to put them up on a public link.

Best bet there would be to email them to support@stardock.com with linking to this thread for reference...

Reason for Karma (Optional)
Successfully updated karma reason!
September 12, 2013 12:59:14 AM from Stardock Forums Stardock Forums

Heh, why, do none of the staff read these?  This would be my first post here so you can consider me a forum newbie.

Reason for Karma (Optional)
Successfully updated karma reason!
September 12, 2013 1:03:51 AM from WinCustomize Forums WinCustomize Forums

Quoting mabreedlove,
Heh, why, do none of the staff read these?

Neil is "the guy" for Windowblinds at Stardock.  He is exactly who you want to read this.

Reason for Karma (Optional)
Successfully updated karma reason!
September 12, 2013 1:29:55 AM from Stardock Forums Stardock Forums

Ah, gotcha.  I considered opening a support ticket originally but felt it would be best to post on here initially so anyone with similar issues could use this as a reference and not have duplicate posts for the same issue or leave people in the dark.

Reason for Karma (Optional)
Successfully updated karma reason!
September 12, 2013 9:12:58 AM from Stardock Forums Stardock Forums

The support staff reads these forums too. 

Reason for Karma (Optional)
Successfully updated karma reason!
September 14, 2013 2:36:50 AM from Stardock Forums Stardock Forums

It appears you might be right about it not being caused by WB.  It seems to be ModernMix holding the all the handles and letting them build-up.  I still hadn't had a chance to reboot yet and found my explorer.exe process baloon to 4000+ handles with the same event errors previously.  The only active Thread within the process was MMix64.dll that was being spawned from the external ModernMix processes.  Killing the threads only resulted in more popping up while.  Killing the processes let the threads die out but before I could shut down the service itself, an identical explorer.exe process popped up now with 2 explorer.exe processes running with the same symptoms.  Shutting down the service, killing the extra process, and terminating the relevant threads immediately dropped the GDI handles down to what they were should be, around 1800 or so from yesterday.

While I never use modern apps, I can say I have removed some of them which resulted in most refusing to start after awhile which I attributed more to my removing something necessary rather than anything the result of ModernMix.  Still, with the ModernMix thread being the only active thread in the GDI balooning process while WB remained completely inactive, left little else to be the actual cause.  

My question at this point would be what, if any, modern app is necessary to keep ModernMix stable or if that isn't the root of the problem, could it possibly be the separation from the rendering explorer.exe and the explorer.exe used for handling browser frames as both have the ModernMix modules injected into each?  Any thoughts?

 

In addition, as a result of the immediate change, DWM has dropped from 740mb usage down to 427mb which I find pretty substantial for such a swift change.  I think it's likely WB just put extra strain that quickened the issues surfacing and is probably safe to re-enable. 

Reason for Karma (Optional)
Successfully updated karma reason!
September 14, 2013 6:29:50 AM from Stardock Forums Stardock Forums

So you had an ever increasing number of threads in explorer being created?

Reason for Karma (Optional)
Successfully updated karma reason!
September 14, 2013 11:47:45 PM from Stardock Forums Stardock Forums

No, it doesn't seem to manifest that way.  The primary explorer.exe runs smoothly with ModernMix and never balloons in size but the secondary one that handles the browser frames and the rest has a MMix_64.dll thread in it reflecting the stacktrace below and it's also the only thread that constantly consumes cycles in the process.  I have a feeling this probably has something to do with a lack of the immerserviceshell being present in the second process since it has no relevance there anyway.  Not to mention, as long as this problem goes on whether its the secondary explorer.exe or not, all modern apps fail to load onto the desktop.  I don't recall this being an issue before I had set Windows to split the explorer processes but then again, I don't use the modern UI all that frequently anyway.  

 

Here, I have started Windows running and set appverif to check for invalid HANDLE usages within the second explorer.exe process.  Obviously it found some.

 

APPLICATION_VERIFIER_HANDLES_INVALID_HANDLE (300)
Invalid handle exception for current stack trace.
This stop is generated if the function on the top of the stack passed an
invalid handle to system routines. Usually a simple kb command will reveal
what is the value of the handle passed (must be one of the parameters -
usually the first one). If the value is null then this is clearly wrong.
If the value looks ok you need to use !htrace debugger extension to get a
history of operations pertaining to this handle value. In most cases it
must be that the handle value is used after being closed.
Arguments:
Arg1: ffffffffc0000008, Exception code.
Arg2: 0000000000000000, Exception record. Use .exr to display it.
Arg3: 0000000000000000, Context record. Use .cxr to display it.
Arg4: 0000000000000000, Not used.

FAULTING_IP:
ntdll!KiRaiseUserExceptionDispatcher+3a
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h]

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 000007fda3744c39 (ntdll!KiRaiseUserExceptionDispatcher+0x000000000000003a)
ExceptionCode: c0000008 (Invalid handle)
ExceptionFlags: 00000000
NumberParameters: 0
Thread tried to close a handle that was invalid or illegal to close

FAULTING_THREAD: 00000000000018b0
DEFAULT_BUCKET_ID: WRONG_SYMBOLS
PROCESS_NAME: explorer.exe
BAD_HANDLE: 00000000000018b0 (!htrace 00000000000018b0)
ERROR_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.
EXCEPTION_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.
NTGLOBALFLAG: 2000100
APPLICATION_VERIFIER_FLAGS: 80600045
APP: explorer.exe

MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x18b0 (2)
Child-SP RetAddr Call Site

PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
LAST_CONTROL_TRANSFER: from 000007fd9e468215 to 000007fda3744c39

STACK_TEXT:
00000000`0b67f080 000007fd`9e468215 : 00000000`00000002 000007fd`8d1fe295 00000000`00000000 00000000`00000002 : ntdll!KiRaiseUserExceptionDispatcher+0x3a
00000000`0b67f150 000007fd`a06c12d2 : 00000000`00000002 00000000`0b67f5e0 00000000`00000000 00000000`00000003 : vfbasics+0x18215
00000000`0b67f190 000007fd`9e4680cf : 00000000`0036ee80 000007f7`6e4ee000 45524157`00000000 00000000`00000000 : KERNELBASE!WaitForMultipleObjectsEx+0xe5
00000000`0b67f470 000007fd`9e468171 : 00000000`0036ee80 00000000`0b67f5e0 00000000`00000000 00000000`00000002 : vfbasics+0x180cf
00000000`0b67f4b0 000007fd`a12e1282 : 00000000`00000000 000007fd`9e456126 00000000`00000000 00000000`00000000 : vfbasics+0x18171
00000000`0b67f500 000007fd`9e467e23 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!WaitForMultipleObjects+0x12
00000000`0b67f540 000007fd`9e467e8a : 00000000`523511d8 00000000`0b67f6b0 000007fd`8d21ed90 00000000`00000000 : vfbasics+0x17e23
00000000`0b67f570 000007fd`8d1d8c17 : 01ceb1b5`a0f4bb87 00000000`0b67f6b0 00000000`523511d8 00000000`000003f0 : vfbasics+0x17e8a
00000000`0b67f5b0 000007fd`8d1ff74b : 00000000`0a6e4d30 00000000`00000000 00000000`00000000 000007fd`9e457500 : MMix_64!InitTW+0x527
00000000`0b67f730 000007fd`8d1ff7d5 : 000007fd`8d231c40 00000000`0a6e4d30 00000000`00000000 00000000`00000000 : MMix_64!NBString+0xa5eb
00000000`0b67f760 000007fd`9e46c1d5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : MMix_64!NBString+0xa675
00000000`0b67f790 000007fd`a12e1832 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : vfbasics+0x1c1d5
00000000`0b67f7d0 000007fd`a379d609 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x1a
00000000`0b67f800 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d


FOLLOWUP_IP:
MMix_64!InitTW+527
000007fd`8d1d8c17 83f801 cmp eax,1

SYMBOL_STACK_INDEX: 8
SYMBOL_NAME: mmix_64!InitTW+527
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: MMix_64
IMAGE_NAME: MMix_64.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 51decfdc
STACK_COMMAND: ~2s ; kb
FAILURE_BUCKET_ID: WRONG_SYMBOLS_c0000008_MMix_64.dll!InitTW
BUCKET_ID: APPLICATION_FAULT_WRONG_SYMBOLS_mmix_64!InitTW+527

Followup: MachineOwner
---------

(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002> g
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002> g
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002> g
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002>
0:002> g
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002> g
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002> g
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002> g
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002> g
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!KiRaiseUserExceptionDispatcher+0x3a:
000007fd`a3744c39 8b8424c0000000 mov eax,dword ptr [rsp+0C0h] ss:00000000`0b67f140=080000c0
0:002> g

 

 

At this point I disabled "Invalid Handle" management and let it run to see if it stops....it doesn't.

(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)
(2ea4.18b0): Invalid handle - code c0000008 (first chance)

 

Here's the relevant function that's your problem:

 

.text:0000000180008A10 ; void __cdecl sub_180008A10(void *)
.text:0000000180008A10 sub_180008A10 proc near ; DATA XREF: sub_180008800+1Bo
.text:0000000180008A10 ; .rdata:000000018005C4D8o ...
.text:0000000180008A10
.text:0000000180008A10 var_150 = qword ptr -150h
.text:0000000180008A10 Handles = qword ptr -140h
.text:0000000180008A10 var_130 = byte ptr -130h
.text:0000000180008A10 var_110 = byte ptr -110h
.text:0000000180008A10 var_10 = qword ptr -10h
.text:0000000180008A10 arg_0 = qword ptr 10h
.text:0000000180008A10 arg_8 = qword ptr 18h
.text:0000000180008A10 arg_10 = qword ptr 20h
.text:0000000180008A10
.text:0000000180008A10 mov [rsp-8+arg_10], rdi
.text:0000000180008A15 push rbp
.text:0000000180008A16 lea rbp, [rsp-70h]
.text:0000000180008A1B sub rsp, 170h
.text:0000000180008A22 mov rax, cs:qword_180061278
.text:0000000180008A29 xor rax, rsp
.text:0000000180008A2C mov [rbp+70h+var_10], rax
.text:0000000180008A30 xor r9d, r9d ; lpName
.text:0000000180008A33 xor r8d, r8d ; bInitialState
.text:0000000180008A36 xor edx, edx ; bManualReset
.text:0000000180008A38 xor ecx, ecx ; lpEventAttributes
.text:0000000180008A3A call cs:CreateEventA
.text:0000000180008A40 lea rcx, sub_18000D0E0 ; void (__cdecl *)(void *)
.text:0000000180008A47 xor r8d, r8d ; void *
.text:0000000180008A4A xor edx, edx ; unsigned int
.text:0000000180008A4C mov rdi, rax
.text:0000000180008A4F mov [rsp+170h+Handles], rax
.text:0000000180008A54 call _beginthread
.text:0000000180008A59 xor r8d, r8d ; bWaitAll
.text:0000000180008A5C lea rdx, [rsp+170h+Handles] ; lpHandles
.text:0000000180008A61 lea ecx, [r8+1] ; nCount
.text:0000000180008A65 mov r9d, 493E0h ; dwMilliseconds
.text:0000000180008A6B call cs:WaitForMultipleObjects
.text:0000000180008A71 cmp eax, 1
.text:0000000180008A74 jnz short loc_180008A91
.text:0000000180008A76 mov rcx, cs:hEvent ; hEvent
.text:0000000180008A7D call cs:SetEvent
.text:0000000180008A83 mov rcx, rdi ; hObject
.text:0000000180008A86 call cs:CloseHandle
.text:0000000180008A8C jmp loc_180008C5C
.text:0000000180008A91 ; ---------------------------------------------------------------------------
.text:0000000180008A91
.text:0000000180008A91 loc_180008A91: ; CODE XREF: sub_180008A10+64j
.text:0000000180008A91 ; DATA XREF: .rdata:000000018005C4D8o ...
.text:0000000180008A91 mov [rsp+170h+arg_0], rbx
.text:0000000180008A99 mov [rsp+170h+arg_8], rsi
.text:0000000180008AA1 call sub_180006F70
.text:0000000180008AA6 lea rsi, aMmix_ini_0 ; "MMix.ini"
.text:0000000180008AAD test eax, eax
.text:0000000180008AAF jz loc_180008B40
.text:0000000180008AB5 lea rdx, [rsp+170h+var_130] ; char *
.text:0000000180008ABA mov r8d, 0Ah ; int
.text:0000000180008AC0 xor ecx, ecx ; int
.text:0000000180008AC2 call _itoa
.text:0000000180008AC7 lea r9, [rsp+170h+var_110]
.text:0000000180008ACC lea r8, [rsp+170h+var_130]
.text:0000000180008AD1 lea rdx, aChecked81 ; "Checked81"
.text:0000000180008AD8 lea rcx, aModernmix ; "ModernMix"
.text:0000000180008ADF mov [rsp+170h+var_150], rsi
.text:0000000180008AE4 call sub_180008360
.text:0000000180008AE9 lea rcx, [rsp+170h+var_110]
.text:0000000180008AEE call sub_18002EE1C
.text:0000000180008AF3 test eax, eax
.text:0000000180008AF5 jnz short loc_180008B40
.text:0000000180008AF7 lea rdx, a1 ; "1"
.text:0000000180008AFE lea rcx, aChecked81 ; "Checked81"
.text:0000000180008B05 call sub_180008510
.text:0000000180008B0A mov ecx, dword ptr [rsp+170h+Handles]
.text:0000000180008B0E lea rdx, [rsp+170h+var_110] ; char *
.text:0000000180008B13 add ecx, 93A80h ; int
.text:0000000180008B19 mov r8d, 0Ah ; int
.text:0000000180008B1F call _itoa
.text:0000000180008B24 lea rdx, [rsp+170h+var_110] ; int
.text:0000000180008B29 lea rcx, aLastupdatechec ; "LastUpdateCheck"
.text:0000000180008B30 call sub_180008510
.text:0000000180008B35 call sub_18000CD90
.text:0000000180008B3A nop word ptr [rax+rax+00h]
.text:0000000180008B40
.text:0000000180008B40 loc_180008B40: ; CODE XREF: sub_180008A10+9Fj
.text:0000000180008B40 ; sub_180008A10+E5j ...
.text:0000000180008B40 xor ecx, ecx ; __time64_t *
.text:0000000180008B42 call _time64
.text:0000000180008B47 mov r8d, 0Ah ; int
.text:0000000180008B4D lea rdx, [rsp+170h+var_130] ; char *
.text:0000000180008B52 lea ecx, [r8-9] ; int
.text:0000000180008B56 mov rbx, rax
.text:0000000180008B59 call _itoa
.text:0000000180008B5E lea r9, [rsp+170h+var_110]
.text:0000000180008B63 lea r8, [rsp+170h+var_130]
.text:0000000180008B68 lea rdx, aAllowautoupdat ; "AllowAutoUpdateCheck"
.text:0000000180008B6F lea rcx, aModernmix ; "ModernMix"
.text:0000000180008B76 mov [rsp+170h+var_150], rsi
.text:0000000180008B7B call sub_180008360
.text:0000000180008B80 lea rcx, [rsp+170h+var_110]
.text:0000000180008B85 call sub_18002EE1C
.text:0000000180008B8A cmp eax, 1
.text:0000000180008B8D jnz short loc_180008BFF
.text:0000000180008B8F lea r8d, [rax+9] ; int
.text:0000000180008B93 lea rdx, [rsp+170h+var_130] ; char *
.text:0000000180008B98 xor ecx, ecx ; int
.text:0000000180008B9A call _itoa
.text:0000000180008B9F lea r9, [rsp+170h+var_110]
.text:0000000180008BA4 lea r8, [rsp+170h+var_130]
.text:0000000180008BA9 lea rdx, aLastupdatechec ; "LastUpdateCheck"
.text:0000000180008BB0 lea rcx, aModernmix ; "ModernMix"
.text:0000000180008BB7 mov [rsp+170h+var_150], rsi
.text:0000000180008BBC call sub_180008360
.text:0000000180008BC1 lea rcx, [rsp+170h+var_110]
.text:0000000180008BC6 call sub_18002EE1C
.text:0000000180008BCB mov r11d, eax
.text:0000000180008BCE cmp r11, rbx
.text:0000000180008BD1 jge short loc_180008BFF
.text:0000000180008BD3 lea ecx, [rbx+93A80h] ; int
.text:0000000180008BD9 lea rdx, [rsp+170h+var_110] ; char *
.text:0000000180008BDE mov r8d, 0Ah ; int
.text:0000000180008BE4 call _itoa
.text:0000000180008BE9 lea rdx, [rsp+170h+var_110] ; int
.text:0000000180008BEE lea rcx, aLastupdatechec ; "LastUpdateCheck"
.text:0000000180008BF5 call sub_180008510
.text:0000000180008BFA call sub_18000CD90
.text:0000000180008BFF
.text:0000000180008BFF loc_180008BFF: ; CODE XREF: sub_180008A10+17Dj
.text:0000000180008BFF ; sub_180008A10+1C1j
.text:0000000180008BFF xor r8d, r8d ; bWaitAll
.text:0000000180008C02 lea rdx, [rsp+170h+Handles] ; lpHandles
.text:0000000180008C07 mov r9d, 36EE80h ; dwMilliseconds
.text:0000000180008C0D lea ecx, [r8+2] ; nCount
.text:0000000180008C11 call cs:WaitForMultipleObjects
.text:0000000180008C17 cmp eax, 1

 

You likely can gleam more insight from this than I can although I can always run an instruction trace on it and find out what exactly is going on.  The other option is switching to a single explorer system and seeing the result although I'd prefer to only do that for testing purposes since this setup is far more stable and less expensive than having my IDE's crash taking my code with them.

Reason for Karma (Optional)
Successfully updated karma reason!
September 15, 2013 7:43:07 AM from Stardock Forums Stardock Forums

It looks like that's the update checking code.  By the looks of it one of the handles it was waiting on was invalid and so it loops round the code more often than it should.

This shouldn't cause any leaks, but it does mean it is doing things when it should be sitting in a wait state for an hour.  Thankfully it intentionally caps the loop rate so it will not be using much cpu.

This will be fixed in the next update.  This shouldn't be causing any leaks though as the code is simply looping round, sleeping for 100ms, and checking a registry key.

Reason for Karma (Optional)
Successfully updated karma reason!
September 15, 2013 7:45:39 PM from Stardock Forums Stardock Forums

That's probably the case in this instance since it seems like these wouldn't be GDI handles.  I guess I'll have to do more digging to find out where the GDI handles are being allocated and what's happening to prevent their proper closure.

I think the next easiest step to take would be to run in a single explorer instance to see how things perform.  I don't ever recall there being an issue in that state and with the primary explorer remaining unaffected, I still think the likely issue lies somewhere with the split between the two processes.  Can you say whether or not the MMix plays any role in the secondary explorer process?  I would imagine it would only really have a purpose where the actual immersiveshell resides.  The secondary process doesn't appear to have anything whatsoever to do with the modern UI.  This would also account for the fact that I don't believe this issue has ever appeared for most of your customer base (from reading the forums) since they likely either aren't aware of the new "Launch folder windows in a seperate process" feature that was introduced much less have taken advantage of it.

I know, personally, I ran MMix for at least a month or two without any issues whatsoever so I don't think it's some overlooked flaw in the codebase.  If it were, I imagine there would be more users experiencing this.

Reason for Karma (Optional)
Successfully updated karma reason!
September 23, 2013 7:57:33 AM from Stardock Forums Stardock Forums

Neil,

Got an update for you.  Granted I still think MMix64.dll in the secondary Explorer is a problem, I did find some helpful information after a long hunt that may help other users in the future.  It never made any sense to me that my GPU memory would be the problem triggering the message since I barely can use up 10% of it so I assumed this was just an artificially manufactured problem.  There's also a program named "Bear" that will do totals for each GDI handle type and user handles with a breakdown for each per process.

I started by tracking down what actually triggers the video event error I posted and came across a few registry keys:

For the following:  

http://support.microsoft.com/kb/840342

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SessionPoolSize
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SessionViewSize

The first one changes the heap size per session and the second is for total available session memory across all sessions.  I'm not running a TerminalServer or anything and despite the article saying the defaults are 64/104 for x64, they weren't even close.  Perhaps it's from running Enterprise but who knows.  I changed them to reflect it.

These will likely make the most difference but just in case, I changed the following too:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\UserProcessHandleQuota

The key names alone make it pretty obvious what they change.  Max GDI handles per process (default 10k), and max user obj handles per process (also default 10k).  Upped both to 20k.  I found I was getting those events way before even coming close to any GDI limit so I believe the session sizes are what actually matters.

 

I would get occasional issues with WB alone regardless of MMix with artifacts or performance which now runs far more smoothly.  Maybe it'll help someone else.  The additional memory is deducted from the kernel pool though so people shouldn't go nuts with it.  I haven't be able to do any other extra tests yet due to a Google interview and Facebook recruiter but things have calmed down somewhat at least for a bit.  I was generally under the impression that neither had to do candidate searches seeing as I never applied but maybe its just due to my primary field. *shrugs*

Reason for Karma (Optional)
Successfully updated karma reason!
Stardock Forums v1.0.0.0    #108431  walnut1   Server Load Time: 00:00:00.0000453   Page Render Time:

Home | About | Privacy | Upload Guidelines | Terms of Service | Help
WinCustomize © 2014 Stardock Corporation. All Rights Reserved.