Spat's WebLog (Steve Patrick)

When things go wrong...

"How to crush a DC in 10 easy steps." or, what is debugging anyway?

"How to crush a DC in 10 easy steps." or, what is debugging anyway?

  • Comments 3

 

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

 

 

 

 

 

 

Leave a Comment
  • Please add 6 and 6 and type the answer here:
  • Post
  • Any chance you can give me the real culprit in this instance? It is looking mighty familiar and would save us a lot of time. Please.

  • shoot me a mail at spat@microsoft.com and ill talk to you about it..

    spat

  • Hi Spat

    Your tlist -s output isnt getting wrapped properly when browsing the blog in a browser (WinMgmt is not visible). I assume an RSS reader will do a better job.

    Might be worth checking the next time you post a lengthy post ;-)

    Cheers

    M@

Page 1 of 1 (3 items)