"How to crush a DC in 10 easy steps." or, what is debugging anyway?
Before we move along, I should say that I look at stuff all day long and use all kinds of tools and different methods to fix problems. Many of the cases involve going through some source code of random component X in order to see where things blew up.
As I mentioned in a previous post "Debugging isn't a tool - it's a methodology. Use the knowledge of your system to piece things together in a logical fashion and you'll find the problem. "
This post is a good example of NOT using any code, but a familiar toolset, in order to realize what was going on.
So the day begins with a request to see why a DC is being crushed. CPU is through the roof and they have some SPA data, as well as some Network traces:
I jumped right to the net traces.
Looking at CrushedDC.cap I see 500 requests for LsarLookupNames
Plus repeated calls ~- 370- for group expansions via SamrGetMembersInGroup (this API lists all the members in a group) and the Rids in each request vary..
The data below was from printing the trace to a file, in Ethereal ( ya ya Wireshark I know.. ) and simple searches
4935034 Operation: SamrGetMembersInGroup (25)
4935035 [Request in frame: 44615]
4935036 MEMBER_ARRAY:
4935037 MEMBER_ARRAY
4935038 Referent ID: 0x00020000
4935039 MEMBER_ARRAY:
4935040 Count: 11
4935041 RIDs
4935042 Referent ID: 0x00020004
4935043 MEMBER_ARRAY_rids:
4935044 Max Count: 11
4935045 Rid: 5280
4935046 Rid: 9367
4935047 Rid: 4821
4935048 Rid: 5319
4935049 Rid: 2111
4935050 Rid: 10646
4935051 Rid: 7678
4935052 Rid: 20509
4935053 Rid: 20838
4935054 Rid: 25789
4935055 Rid: 49169
SamrLookupIdsInDomain
Like so -
6640146 Microsoft Security Account Manager, SamrLookupIdsInDomain
6640147 Operation: SamrLookupIdsInDomain (18)
6640148 [Response in frame: 60011]
6640149 Policy Handle: OpenDomain(S-1-5-21-1801674531-152049171-725345543)
6640150 Context Handle: 00000000C86D167810FDB44E8CB81DB5BF41602F
6640151 [Frame handle opened: 59875]
6640152 [Frame handle closed: 60035]
6640153 Count: 26
6640154 LOOKUP_RIDS:
6640155 RIDS:
6640156 Max Count: 1000
6640157 Offset: 0
6640158 Actual Count: 26
6640159 Rid: 6035
6640160 Rid: 5940
6640161 Rid: 6079
6640162 Rid: 7472
6640163 Rid: 5987
6640164 Rid: 5957
etc.. on and on
Once we determined that the source of the CPU utilization was from client machines, we asked for a complete kernel dump from a client the next time the issue occurred.
Of course, the client needed to be identified from a trace taken at the same time. Luckily they were able to do this and found 2 local clients to get data from.
When I got the dumps, what was the goal?
To see what process on the clients was sending over ridiculous amounts of traffic for LookupNames , or similar lookup requests.
In order to do this I first setup a log file using :
.logappend c:\processes.log
And then dumped all stacks for all processes on the machine.
!for_each_process ".process /p /r @#Process;!process @#Process" ( read as: for each process set the process context and reload the usermode symbols, then do a !process to get all stacks for the current process )
Stepped away to work on something else for a bit as both debugger instances chunked through each process and dumped all the stacks to my logfile.
Once I came back it was a simple matter of looking for the string “lookupaccount”
Ahaaa!! There was the bugger. There it was .... WMI.
From the code I could see the paramters passed on for the exact queries being done and dumped these queries from the data in the dump:
These queries, from a number of clients, are ineffecient and cause the DC to enumerate waay to much data to find what the client needs.
select __RELPATH, Domain, Name,SidType from Win32_Group
and
select __RELPATH, GroupComponent from Win32_GroupUser where PartComponent = "Win32_UserAccount.Domain='MyMachine',Name='ASPNET'"
Ahh, you the reader, says he doesnt have the source code to determine this. Well in that case I would enable WMI logging and you can easily see which queries are being performed.
(Rabbit-Trail) WMI LOGGING:
Go to My Computer - right click and Manage. Go to the WMI Control Properties.
Go to the Logging Tab and set to verbose:
Then in the wbemcore.log under \system32\wbem\logs you will see something like this:
(Tue Feb 13 13:50:11 2007.3555718) : DCOM connection from CRISCO1\administrator at authentiction level Privacy, AuthnSvc = 10, AuthzSvc = 0, Capabilities = 0
(Tue Feb 13 13:50:32 2007.3577562) : CALL CWbemNamespace::ExecQuery
BSTR QueryFormat = WQL
BSTR Query = select Domain,Name,SidType from Win32_Group
IEnumWbemClassObject **pEnum = 0xF0CD8
(Tue Feb 13 13:50:32 2007.3577562) : CALL CWbemNamespace::ExecQueryAsync
BSTR QueryFormat = WQL
BSTR Query = select Domain,Name,SidType from Win32_Group
Unfortunately the WMI logs don't show WHO called the WMI query initially, which is kind of important J
So a little more work to be done.
kd> !thread f8f878f8
THREAD f8f878f8 Cid 10f8.0f18 Teb: 7ffdc000 Win32Thread: e21a0eb0 WAIT: (UserRequest) UserMode Alertable
82eec2f8 NotificationEvent
IRP List:
fea86008: (0006,01b4) Flags: 00000900 Mdl: ff63df00
Impersonation token: e15b3030 (Level Impersonation)
Owning Process ff484200 Image: wmiprvse.exe
Wait Start TickCount 34339718 Ticks: 2 (0:00:00:00.020)
Context Switch Count 34558 LargeStack
UserTime 00:00:00.0971
KernelTime 00:00:03.0084
Win32 Start Address 0x009de175
LPC Server thread working on message Id 9de175
Start Address kernel32!BaseThreadStartThunk (0x7c810659)
Stack Init f17ad000 Current f17acca0 Base f17ad000 Limit f17a9000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f17accb8 804dc0f7 f8f87968 f8f878f8 804dc143 nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
f17accc4 804dc143 00000000 00000000 00000000 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f17accec 8056539e 00000001 00000006 ffffff01 nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f17acd50 804de7ec 0000014d 00000001 00000000 nt!NtWaitForSingleObject+0x9a (FPO: [Non-Fpo])
f17acd50 7c90eb94 0000014d 00000001 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f17acd64)
0090e52c 7c90e9c0 7c8025cb 0000014d 00000001 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0090e530 7c8025cb 0000014d 00000001 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
0090e594 77e80acb 0000014d ffffffff 00000001 kernel32!WaitForSingleObjectEx+0xa8 (FPO: [Non-Fpo])
0090e5b0 77e80a81 000c58ac 00000001 ffffffff RPCRT4!UTIL_WaitForSyncIO+0x20 (FPO: [Non-Fpo])
0090e5d4 77e852c7 000c5878 000c58ac 0090e604 RPCRT4!UTIL_GetOverlappedResultEx+0x1d (FPO: [Non-Fpo])
0090e5fc 77e8520d 000c5878 0090e734 0090e730 RPCRT4!CO_SyncRecv+0x71 (FPO: [Non-Fpo])
0090e61c 77e80e8d 000bcd18 00000060 0090e734 RPCRT4!OSF_CCONNECTION::TransSendReceive+0x9d (FPO: [Non-Fpo])
0090e698 77e80e0d 000bcd18 0012bd80 00000001 RPCRT4!OSF_CCONNECTION::SendFragment+0x226 (FPO: [Non-Fpo])
0090e6f0 77e80c6f 00000000 00000048 0090e734 RPCRT4!OSF_CCALL::SendNextFragment+0x1d2 (FPO: [Non-Fpo])
0090e738 77e80bbc 0090e7bc 0090e778 00000001 RPCRT4!OSF_CCALL::FastSendReceive+0x144 (FPO: [Non-Fpo])
0090e754 77e8110b 0090e7bc 0090e778 0090e7bc RPCRT4!OSF_CCALL::SendReceiveHelper+0x58 (FPO: [Non-Fpo])
0090e780 77e7a716 000bcd30 0090e7a0 77e7a747 RPCRT4!OSF_CCALL::SendReceive+0x41 (FPO: [Non-Fpo])
0090e78c 77e7a747 0090e7bc 77ddf370 0090eb98 RPCRT4!I_RpcSendReceive+0x24 (FPO: [Non-Fpo])
0090e7a0 77ef3675 0090e7e8 000bcd78 000aef22 RPCRT4!NdrSendReceive+0x2b (FPO: [Non-Fpo])
0090eb7c 77de1cd0 77ddf370 77de1374 0090eb98 RPCRT4!NdrClientCall2+0x222 (FPO: [Non-Fpo])
0090eb90 77de1c52 000aef10 0090ec04 00000800 ADVAPI32!LsarOpenPolicy2+0x1b (FPO: [Non-Fpo])
0090ebe4 77df9202 0090ec30 0090ec04 00000800 ADVAPI32!LsaOpenPolicy+0x95 (FPO: [Non-Fpo])
0090ec4c 77df9195 007e2aec 007e46bc 007f8958 ADVAPI32!LookupAccountNameInternal+0x6c (FPO: [Non-Fpo])
0090ec74 716e44ff 007e2aec 007e46bc 007f8958 ADVAPI32!LookupAccountNameW+0x21 (FPO: [Non-Fpo])
0090ecec 716e4ab5 007e387c 007dfef4 00000049 cimwin32!CSid::InitFromAccountName+0x10e (FPO: [Non-Fpo])
0090ed18 7166172b 000c7dcc 00135d90 007dfef4 cimwin32!CSid::CSid+0x91 (FPO: [Non-Fpo])
0090ed80 71661e3f 000c7dcc 00135d90 007dfef4 cimwin32!CWin32GroupAccount::GetSIDInformationW+0x32 (FPO: [Non-Fpo])
0090ee2c 71662cf5 0090ee68 000c7dcc 007e0170 cimwin32!CWin32GroupAccount::GetDomainGroupsNT+0x1ea (FPO: [Non-Fpo])
0090ee9c 71662d49 007e0170 0090ef58 71662801 cimwin32!CWin32GroupAccount::AddDynamicInstancesNT+0x15c (FPO: [Non-Fpo])
0090eea8 71662801 007e0170 00000000 007e0170 cimwin32!CWin32GroupAccount::EnumerateInstances+0xd (FPO: [Non-Fpo])
0090ef58 692cb732 007e0170 0090efa8 00000000 cimwin32!CWin32GroupAccount::ExecQuery+0x2f1 (FPO: [Non-Fpo])
0090ef78 692cf589 007e0170 0090efa8 00000000 framedyn!Provider::ExecuteQuery+0x5d (FPO: [Non-Fpo])
0090f498 01019a6e 007df460 000b6a1c 000c5554 framedyn!CWbemProviderGlue::ExecQueryAsync+0x258 (FPO: [Non-Fpo])
0090f510 01019c19 00000000 000b735c 000b5abc wmiprvse!CInterceptor_IWbemSyncProvider::Helper_ExecQueryAsync+0x453 (FPO: [Non-Fpo])
0090f558 77e79dc9 007df460 000b735c 000b5abc wmiprvse!CInterceptor_IWbemSyncProvider::ExecQueryAsync+0x85 (FPO: [Non-Fpo])
0090f584 77ef321a 01019b94 0090f598 00000006 RPCRT4!Invoke+0x30
0090f998 77ef3bf3 000c3650 000b61dc 000b3a7c RPCRT4!NdrStubCall2+0x297 (FPO: [Non-Fpo])
0090f9f0 756bd7fe 000c3650 000b3a7c 000b61dc RPCRT4!CStdStubBuffer_Invoke+0xc6 (FPO: [Non-Fpo])
0090fa04 77600c31 0062138c 000b3a7c 000b61dc FastProx!CBaseStublet::Invoke+0x22 (FPO: [Non-Fpo])
0090fa44 77600bdb 000b3a7c 000c3558 000b0d84 ole32!SyncStubInvoke+0x33 (FPO: [Non-Fpo])
Note the part about :
LPC Server thread working on message Id 9de175
Hrmm it’s a client thread crunching on something as a result of a request ( via a local procedure call ) .
Who requested this work to be done?
We can identify the caller from the !lpc command in the debugger:
kd> !lpc message 9de175
Searching message 9de175 in threads ...
Client thread feb57258 waiting a reply from 9de175
Server thread f8f878f8 is working on message 9de175
Searching thread feb57258 in port rundown queues ...
Server communication port 0xe1a199a8
Handles: 1 References: 1
The LpcDataInfoChainHead queue is empty
Connected port: 0xe136d1b0 Server connection port: 0xe1449c88
Client communication port 0xe136d1b0
Handles: 1 References: 3
The LpcDataInfoChainHead queue is empty
Server connection port e1449c88 Name: OLE65F8F553791346168D792BA5E0BA
Handles: 1 References: 16
Server process : ff484200 (wmiprvse.exe)
Queue semaphore : ff3411a0
Semaphore state 0 (0x0)
The message queue is empty
Messages in LpcDataInfoChainHead:
0000 e192eea0 - Busy Id=009de168 From: 0364.17f4 Context=80040002 [e1449d08 . e2347a18]
Length=0044002c Type=00380001 (LPC_REQUEST)
Data: 00020001 00150342 0000680c 000010f8 6c0a3a88 b3c28d12
0000 e2347a18 - Busy Id=009de175 From: 0364.1138 Context=80040002 [e192eea0 . e1449d08]
Length=0044002c Type=00380001 (LPC_REQUEST)
Data: 00020d01 00150342 0000680c 000010f8 6c0a3a88 b3c28d12
The LpcDataInfoChainHead queue contains 2 messages
Threads in RunDown queue : 0xe192ecd8 0xe2347850
Done.
kd> !thread feb57258
THREAD feb57258 Cid 0364.1138 Teb: 7ffad000 Win32Thread: e1a17830 WAIT: (WrLpcReply) UserMode Non-Alertable
feb5744c Semaphore Limit 0x1
Waiting for reply to LPC MessageId 009de175: ( we can see it waiting on the reply here )
Current LPC port e136d1b0
Impersonation token: e27ccde0 (Level Impersonation)
Owning Process 82d43a88 Image: svchost.exe
Wait Start TickCount 34241510 Ticks: 98210 (0:00:16:23.514)
Context Switch Count 78 LargeStack
UserTime 00:00:00.0010
KernelTime 00:00:00.0000
Win32 Start Address wbemcore!CCoreQueue::_ThreadEntry (0x762cf010)
Start Address kernel32!BaseThreadStartThunk (0x7c810659)
Stack Init f1dd1000 Current f1dd0c50 Base f1dd1000 Limit f1dcd000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.
ChildEBP RetAddr Args to Child
f1dd0c68 804dc0f7 feb572c8 feb57258 804dc143 nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
f1dd0c74 804dc143 feb5744c feb57420 feb57258 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f1dd0c9c 8057719a 00000001 00000011 012df501 nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f1dd0d50 804de7ec 000019d8 04882518 04882518 nt!NtRequestWaitReplyPort+0x63d (FPO: [Non-Fpo])
f1dd0d50 7c90eb94 000019d8 04882518 04882518 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f1dd0d64)
012df5e0 7c90e3ed 77e7c968 000019d8 04882518 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
012df5e4 77e7c968 000019d8 04882518 04882518 ntdll!ZwRequestWaitReplyPort+0xc (FPO: [3,0,0])
012df630 77e7a716 04793008 012df658 776016bf RPCRT4!LRPC_CCALL::SendReceive+0x228 (FPO: [Non-Fpo])
012df63c 776016bf 0262d424 0476366c 012df73c RPCRT4!I_RpcSendReceive+0x24 (FPO: [Non-Fpo])
012df658 776011b6 00000000 00000000 00000000 ole32!ThreadSendReceive+0xf5 (FPO: [Non-Fpo])
012df674 7760109a 012df73c 012df84c 0476366c ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0x13d (FPO: [Non-Fpo])
012df754 7751047c 0476366c 012df84c 012df83c ole32!CRpcChannelBuffer::SendReceive2+0xb9 (FPO: [Non-Fpo])
012df7c0 77510414 0476366c 012df84c 012df83c ole32!CAptRpcChnl::SendReceive+0xab (FPO: [Non-Fpo])
012df814 77ef3db5 0476366c 012df84c 012df83c ole32!CCtxComChnl::SendReceive+0x113 (FPO: [Non-Fpo])
012df830 77ef3eac 0478abc4 012df878 0600015b RPCRT4!NdrProxySendReceive+0x43 (FPO: [Non-Fpo])
012dfc0c 77ef3e42 74ed1bb0 74ed176e 012dfc44 RPCRT4!NdrClientCall2+0x1fa (FPO: [Non-Fpo])
012dfc2c 77e89aa4 0000001c 00000015 012dfc78 RPCRT4!ObjectStublessClient+0x8b (FPO: [Non-Fpo])
012dfc3c 756cd8b0 0478abc4 047947dc 0514181c RPCRT4!ObjectStubless+0xf
012dfc78 59818b63 047947dc 0514181c 0514181c FastProx!CWbemSvcWrapper::XWbemServices::ExecQueryAsync+0x93 (FPO: [Non-Fpo])
012dfce8 762e9c29 047a1ec8 0488332c 0482391c wmiprvsd!CInterceptor_IWbemProvider::ExecQueryAsync+0x1d2 (FPO: [Non-Fpo])
012dfd60 763118e5 051c63b8 0482391c 0488332c wbemcore!CWbemNamespace::Exec_DynAux_ExecQueryAsync+0x1bf (FPO: [Non-Fpo])
012dfd7c 762cef24 00000000 0190e740 00000000 wbemcore!CMergerDynReq_DynAux_ExecQueryAsync::Execute+0x1a (FPO: [0,0,0])
012dfda8 762ced4e 0190e740 00000000 0190e740 wbemcore!CCoreQueue::pExecute+0x3c (FPO: [Non-Fpo])
012dfdd8 762f25cb 022a9f28 023546e8 022a9f28 wbemcore!CCoreQueue::Execute+0x18 (FPO: [Non-Fpo])
012dfe20 762cdecc 022a9f28 0297a1e8 022d8d38 wbemcore!CWbemQueue::Execute+0xf6 (FPO: [Non-Fpo])
012dfe38 7630d438 0190e740 00000000 023546e8 wbemcore!CCoreQueue::ExecSubRequest+0x32 (FPO: [Non-Fpo])
012dfe80 763117fe 0190e740 01868ff8 00000000 wbemcore!CWmiMerger::Exec_MergerParentRequest+0x11a (FPO: [Non-Fpo])
012dfeac 762cef24 00000000 023546e8 00000000 wbemcore!CMergerParentReq::Execute+0x23 (FPO: [Non-Fpo])
012dfed8 762ced4e 023546e8 00000000 023546e8 wbemcore!CCoreQueue::pExecute+0x3c (FPO: [Non-Fpo])
012dff08 762f25cb 022a9f28 022a9f28 0194ff10 wbemcore!CCoreQueue::Execute+0x18 (FPO: [Non-Fpo])
012dff50 762cee89 022a9f28 022a9f28 7c809766 wbemcore!CWbemQueue::Execute+0xf6 (FPO: [Non-Fpo])
012dff84 762cf055 00002ee0 03a2eff8 00090000 wbemcore!CCoreQueue::ThreadMain+0x111 (FPO: [Non-Fpo])
012dffb4 7c80b683 022a9f28 03a2eff8 00090000 wbemcore!CCoreQueue::_ThreadEntry+0x45 (FPO: [Non-Fpo])
012dffec 00000000 762cf010 022a9f28 00000000 kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])
Ahhh svchost.exe – makes sense since it hosts the wimgmt goo.
Tlist –s shows us:
c:\debugger\tlist –s
1048 svchost.exe Svcs: Audiosrv,Dhcp,Eventlog,lmhosts,wscsvc
1092 svchost.exe Svcs: AudioEndpointBuilder,CscService,EMDMgmt,Netman,PcaSvc,SysMain,TabletInputService,TrkWks,UmRd
pService,UxSms,WdiSystemHost,WPDBusEnum,wudfsvc
1104 svchost.exe Svcs: AeLookupSvc,Appinfo,AppMgmt,BITS,CertPropSvc,gpsvc,hkmsvc,IKEEXT,iphlpsvc,LanmanServer,MMCSS
,ProfSvc,RasMan,Schedule,seclogon,SENS,SessionEnv,ShellHWDetection,Themes,Winmgmt,wuauserv
Hrmm now who asked WMI for the info?
Looking through svchost.exe process info I see other threads , but these are server threads processing data:
kd> !thread ff59b150
THREAD ff59b150 Cid 0364.1580 Teb: 7ffaa000 Win32Thread: e160fd88 WAIT: (UserRequest) UserMode Non-Alertable
81ed03a0 NotificationEvent
ff583058 SynchronizationEvent
Not impersonating
DeviceMap e1009570
Owning Process 82d43a88 Image: svchost.exe
Wait Start TickCount 34241509 Ticks: 98211 (0:00:16:23.524)
Context Switch Count 628 LargeStack
UserTime 00:00:00.080
KernelTime 00:00:00.040
Win32 Start Address 0x009de165
LPC Server thread working on message Id 9de165
Start Address kernel32!BaseThreadStartThunk (0x7c810659)
Stack Init f19df000 Current f19de95c Base f19df000 Limit f19dc000 Call 0
Priority 9 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Lo and behold, on the first process I looked at we saw this:
We can use the same !lpc command to see who was processing this message:
kd> !lpc message 9de165
Searching message 9de165 in threads ...
Server thread ff59b150 is working on message 9de165
Client thread f8f5c4e8 waiting a reply from 9de165
Searching thread f8f5c4e8 in port rundown queues ...
THREAD f8f5c4e8 Cid 1084.0f4c Teb: 7ffdf000 Win32Thread: e1b0dc30 WAIT: (WrLpcReply) UserMode Non-Alertable
f8f5c6dc Semaphore Limit 0x1
Waiting for reply to LPC MessageId 009de165:
Current LPC port e1a5e230
Not impersonating
DeviceMap e1009570
Owning Process ff71d4d0 Image: badapp.exe
ChildEBP RetAddr Args to Child
f1aaec68 804dc0f7 f8f5c558 f8f5c4e8 804dc143 nt!KiSwapContext+0x2e
f1aaec74 804dc143 f8f5c6dc f8f5c6b0 f8f5c4e8 nt!KiSwapThread+0x46
f1aaec9c 8057719a 00000001 00000011 00000201 nt!KeWaitForSingleObject+0x1c2
f1aaed50 804de7ec 00000118 0014b770 0014b770 nt!NtRequestWaitReplyPort+0x63d
f1aaed50 7c90eb94 00000118 0014b770 0014b770 nt!KiFastCallEntry+0xf8
00118804 7c90e3ed 77e7c968 00000118 0014b770 ntdll!KiFastSystemCallRet
00118808 77e7c968 00000118 0014b770 0014b770 ntdll!ZwRequestWaitReplyPort+0xc
00118854 77e7a716 00163878 0011887c 776016bf RPCRT4!LRPC_CCALL::SendReceive+0x228
00118860 776016bf 001596f4 00156f7c 00118960 RPCRT4!I_RpcSendReceive+0x24
0011887c 776011b6 00000000 00000000 00000000 ole32!ThreadSendReceive+0xf5
00118898 7760109a 00118960 00118a70 00156f7c ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0x13d
00118978 7751047c 00156f7c 00118a70 00118a60 ole32!CRpcChannelBuffer::SendReceive2+0xb9
001189e4 77510414 00156f7c 00118a70 00118a60 ole32!CAptRpcChnl::SendReceive+0xab
00118a38 77ef3db5 00156f7c 00118a70 00118a60 ole32!CCtxComChnl::SendReceive+0x113
00118a54 77ef3eac 0015c15c 00118a9c 0600015b RPCRT4!NdrProxySendReceive+0x43
00118e30 77ef3e42 74ed1bb0 74ed1732 00118e68 RPCRT4!NdrClientCall2+0x1fa
00118e50 77e89aa4 0000001c 00000014 00118e9c RPCRT4!ObjectStublessClient+0x8b
00118e60 756cd7e1 0015c15c 001560e4 00163784 RPCRT4!ObjectStubless+0xf
00118e9c 004047eb 001560e4 00163784 00163784 fastprox!CWbemSvcWrapper::XWbemServices::ExecQuery+0x8e
WARNING: Stack unwind information not available. Following frames may be wrong.
00162044 00000000 00000000 00030004 0008019e BadApp+0x47eb
So – we go back and reconfigure badapp.exe ( of course it wasn’t the real name, the real app is a well known one I don’t think I can mention here ) to NOT do such terribly expensive WMI queries contantly… and no more DC being crushed.
Yay. :)
Spatdsg
