hmm https://docs.microsoft.com/archive/blogs/hmm/feed.xml Faik Hakan Bilgen Wed, 17 Apr 2019 03:22:02 GMT en-US hourly 1 WaitChain https://docs.microsoft.com/archive/blogs/hmm/waitchain Sun, 18 Feb 2018 14:12:30 GMT https://blogs.msdn.microsoft.com/hmm/?p=175 Analyze wait chain" added to Windows Vista. This feature was accessible through Resource Monitor until Windows 8. [caption id="attachment_185" align="alignnone" width="659"] Analyze wait chain accessed from Resource Monitor[/caption] And it is accessible via Task Manager since Windows 8. [caption id="attachment_376" align="alignnone" width="718"] "Analyze wait chain" accessed through Task Manager[/caption] As a Premier Field Engineer, I’m in frequent contact with developers and administrators from different industries and countries. Whenever, I mention Wait Chain Analyzer I’m surprized to see that many people are not aware of it. I get surprized because it is a powerful feature to see whether a process is waiting on something that is noticable w/o attaching the debugger. The feature has its limitations but still very useful. Recently, I was approached by a customer to solve the hang/freeze problems of their LOB application. The catch was that there are around 20K end users scattered around 1000 offices. Each end user has usually a non-zero length queue of customers waiting to be served. Hence, it is difficult for the IT support professionals to check the Wait Chain of the relevant process(es) get dump files, etc. To worsen the situation there are many reasons for the hangs. I’ve realized that I didn' know any tool that would generate Wait Chain list for process(es). We have only the UI that can be launched either from Resource Monitor or Task Manager. And, that UI shows one process’s Wait Chain at once. To speed up data collection I’ve developed a simple console based tool called “WaitChain”. It can either collect:
  • Every process’s Wait Chain when no particular process is specified
  • A particular process’s Wait Chain list if the Process ID is specified
  • The Wait Chain list of each process instance of an application if the process name is specified
The WaitChain.exe tool is based on the WCT API example in MSDN. It can also generate the dump file of the particular process(es) and each process that shows up in the Wait Chain list. This feature requires procdump to produce the dump files. If WaitChain is asked to generate the Wait Chain for a particular process it reports all the running processes and their IDs. This comes handy when dump files are generated and a callstack waits on a process that was not captured by WCT API and we want to know the name of the process that thread is waiting on.

How to use WaitChain.exe?

Getting help

“WaitChain.exe /?” documents the functionality of WaitChain.exe.  

Getting the Wait Chain for all processes running on the system

Simply execute WaitChain.exe without any parameters. While executing WaitChain.exe puts a dot for every process that it is going to analyze. When finished the result can be read in the report file. WAITCHAIN_ComputerName.LOG is the report file’s name format and the file is created in the same folder as WaitChain.exe is running. The report has 3 sections:
  • Start Information The command line information and Process ID (in both hex and dec format) of WaitChain.exe is recorded. Also, the start time of the WaitChain.exe is logged. e.g.

PROGRESS INFORMATION ======================================== Command line : "WaitChain.exe" PID          : (0x2F90:0n12176) Started on   : 02/15/2018  14:55:14

 
  • Wait Chain List of each process WaitChain tries to connect to each process and get the Wait List of every thread. WaitChain.exe asks for Elevated Usage. This is to open processes running under different security context than WaitChain.exe. Some processes do not allow to be opened. They will be listed but no information will be available for them. e.g.

Process (0x4:0n4) - N/A ----------------------------------

Process (0x48:0n72) - N/A ----------------------------------

Process (0x24c:0n588) - smss.exe ----------------------------------

Process (0x320:0n800) - csrss.exe ----------------------------------

Process (0x388:0n904) - wininit.exe ----------------------------------

Process (0x3d0:0n976) - services.exe ----------------------------------

Process (0x72d4:0n29396) - SyncWaitTest.exe ---------------------------------- 30424: [72d4:76d8:Blocked]->[End] 17008: [72d4:4270:Blocked]->[End] 25476: [72d4:6384:Blocked]->[CriticalSection:Owned]->[72d4:7688:Blocked]->[CriticalSection:Owned]->[72d4:6384:Blocked]->[End] !!!Deadlock!!! 30344: [72d4:7688:Blocked]->[CriticalSection:Owned]->[72d4:6384:Blocked]->[CriticalSection:Owned]->[72d4:7688:Blocked]->[End] !!!Deadlock!!!

  • End Information Contains the completion time of the WaitChain.exe process. E.g.

PROGRESS INFORMATION ======================================== Finished on  : 02/15/2018  14:55:50

It should take less than a minute to walk each and every process.  

Getting the Wait Chain for a specific process

There are two ways to do this. Either: i. Specify the Process ID ii. Or, provide the process name (including the .exe extension)

Specifying a Process ID

The ProcessID should be passed as an argument to WaitChain.exe. e.g. WaitChain should generate a report for the process with ID 29396. Note: The ProcessID argument should be in decimal format. The report is slightly different than when WaitChain.exe is executed without arguments:
  1. The start and end progress information is just the same.
  2. Only the Wait List of the process whose ProcessID is given is reported.
  3. The ProcessID (in both hex and dec format) and name of all running processes is listed. This list is useful for two cases:
 
  • When the WaitList contains another process than the inspected one. The ProcessID can be looked up from that list and the process name can be retrieved. E.g.

Process (0x7a24:0n31268) - SyncWaitTest.exe ---------------------------------- 9728: [7a24:2600:Blocked]->[End] 21180: [7a24:52bc:Running]->[End] 19380: [7a24:4bb4:Running]->[End] 17168: [7a24:4310:Running]->[End] 22840: [7a24:5938:Blocked]->[ProcWait:Owned]->[4e4c:0:PidOnly]->[End]

Relevant Processes: 0x4e4c->[END]

Thread 22840 of the SyncWaitTest.exe process is waiting on the process with ProcessID 0x4e4c. Now it is time to lookup the process with ProcessID 4e4c.

RUNNING PROCESSES =================

PID(hex:dec)    NAME … 0x4e4c:0n20044 notepad.exe ===> That is the process that the SyncWaitTest.exe process is waiting on.

  • When a dump file is generated and and a callstack is showing that the thread is waiting on another process and the WaitChain.exe does not report a target ProcessID:ThreadID. WCT APIs do not report each and every wait. Therefore, generating a dump file of the inspected process might be useful. And, having a ProcessID:ProcessName list can help to find the target process on which the inspected process is waiting for.
 

Getting the Wait Chain for a specific Process Name

In this case the process name should be provided as an argument. WaitChain.exe will analyze each instance of that application’s process. E.g. it is common to see multiple instances of w3wp.exe, svchost.exe.   This time the report will list each instance of SyncWaitTest.exe’s Wait Chain. E.g. Process (0x7a24:0n31268) - SyncWaitTest.exe ---------------------------------- 9728: [7a24:2600:Blocked]->[End] 22840: [7a24:5938:Blocked]->[ProcWait:Owned]->[4e4c:0:PidOnly]->[End] Relevant Processes: 0x4e4c->[END] Process (0x6e44:0n28228) - SyncWaitTest.exe ---------------------------------- 27980: [6e44:6d4c:Blocked]->[End] 28912: [6e44:70f0:Blocked]->[End] 31704: [6e44:7bd8:Blocked]->[CriticalSection:Owned]->[6e44:3388:Blocked]->[CriticalSection:Owned]->[6e44:7bd8:Blocked]->[End] !!!Deadlock!!! 13192: [6e44:3388:Blocked]->[CriticalSection:Owned]->[6e44:7bd8:Blocked]->[CriticalSection:Owned]->[6e44:3388:Blocked]->[End] !!!Deadlock!!! The report file (WAITCHAIN log) will also contain the start end information of WaitChain.exe and the list of running processes.  

Generating memory dump files

WCT API is nice to detect the reason of some wait types. However, it has its limitations and usually it is required to understand why a process has ended up in that situation. In other words, a call stack information might be necessary. To walk this extra step a memory dump file is needed. WaitChain spawns an instance of ProcDump.exe to generate the memory dump file. “/d” argument will instruct WaitChain.exe to generate dump files. “/d” can be used together with ProcessID or ProcessName arguments.

Generating dumps with ProcessID

In this case WaitChain.exe will generate the dump file of the process with ProcessID. And, it will generate the dump file of the processes which show up in any Wait Chain of the process’s threads. E.g. in the following output the process with ProcID 4e4c is in the Wait Chain of the process 31268 (SyncWaitTest.exe). Process (0x7a24:0n31268) - SyncWaitTest.exe ---------------------------------- 9728: [7a24:2600:Blocked]->[End] 22840: [7a24:5938:Blocked]->[ProcWait:Owned]->[4e4c:0:PidOnly]->[End] Hence, WaitChain.exe will generate a dump file for both processes with ProcessID 31268 and 4e4c.  

Generating dumps with Process Name

In this case WaitChain.exe is supplied with a Process Name. It will note each process that shows up in the Wait Chain of any instance of the ProcessName. At the end it will generate the dump files of each instance of ProcessName and every process that was found to be involved in the Wait Chain lists.  

How to interpret the Wait Chain Output in the WAITCHAIN log file?

WaitChain.exe gets each thread’s Wait Chain. It will list the output no matter there is a WaitChain or not. 9728: [7a24:2600:Blocked]->[End] This line is read as “The thread with ThreadID 9728’s Wait Chain starts with the process with ProcessID 7a24 (31268 in decimal format) and ThreadID 2600 (9728 in decimal format). And, that node is the end node at the same time. Hence, there is no nodes in the Wait Chain. The thread is waiting.” 22840: [7a24:5938:Blocked]->[ProcWait:Owned]->[4e4c:0:PidOnly]->[End] This line is read as “The thread with ThreadID 22840’s Wait Chain starts with the process with ProcessID 7a24 (31268 in decimal format) and ThreadID 5938 (22840 in decimal format). This node is waiting on a Process. That process has a ProcessID 4e4c. And, the process with ProcessID 4e4c has no further nodes in the Wait Chain”. Once the process 4e4c terminates the thread will continue execution. As explained above the WCT API has its limitations in detecting the wait types. The details are documented in Wait Chain Traversal document. I’ve created cases to understand the possible output that I might expect from WCT API. Below, I’ll give an example for each case and add the screen shot of the UI of the “Analyze wait chain” feature, too.  

ALPC

ALPC stands for Asynchronous Local Inter-Process Communication. It is a message based communication implemented in the Windows Kernel. It can be used between user mode processes, between user mode and kernel drivers and between kernel drivers. An example is the LRPC protocol in RPC. It is based on ALPC. To see the outcome I’ve created a RPC server and client application. The client application is making a call to a method on the RPC interface at the server and that call takes long time to finish its execution. When WaitChain.exe is executed the following output is in the WAITHCAIN log file for the process that is waiting the RCP call’s result: 6840: [2600:1ab8:Blocked]->[Alpc:\RPC Control\LRPC-b06e4faaf1376606cd]->[6d00:0:PidOnly]->[End] The line can be read as “Thread 1ab8 (6840 in decimal) of process 2600 (9728 in decimal) is waiting on ALPC request that is an LRPC end point hosted by process 6d00 (27904 in decimal)”. We can expect that once the RPC server process (PID:27904) has completed execution for the LRPC request the waiting process’s (PID:9728) thread (TID:6840) can continue execution. The "Analyze wait chain" for the client process reports as follows:   Just FYI, the RPC EndPoint port listening on the LRPC protocol can be find via winobj.exe as well. In fact, WinObj can list each ALPC Port.   If WaitChain.exe is executed with the “/d” argument then the reason for wait could be understood better with checking the RPC server callstacks. E.g. below is the callstack of the RPC Server process (PID:27904) that is not responding: 0:002> kbn # ChildEBP RetAddr  Args to Child 00 04e7f4d0 7735290b 00000000 04e7f514 e1eb5440 ntdll!NtDelayExecution+0xc 01 04e7f538 7735285f 0001d4c0 00000000 04e7f554 KERNELBASE!SleepEx+0x9b 02 04e7f548 0005225a 0001d4c0 04e7f56c 759f2620 KERNELBASE!Sleep+0xf 03 04e7f554 759f2620 0001d4c0 00000246 00000001 CssRpcSrv!s_ExecuteLong+0x1a [c:\code\css\cssrpcsrv\cssrpcsrvimpl.cpp @ 36] 04 04e7f56c 759b5e98 00052240 04e7f7a0 00000001 rpcrt4!Invoke+0x34 05 04e7f9bc 759b4969 00000000 00000000 0300a178 rpcrt4!NdrStubCall2+0x448 06 04e7f9d8 759dcd40 0300a178 9df72f94 0300a178 rpcrt4!NdrServerCall2+0x19 07 04e7fa1c 759dc78f 00058294 0300a178 04e7faf8 rpcrt4!DispatchToStubInCNoAvrf+0x20 08 04e7fa88 75a10733 0300a178 00000000 00000000 rpcrt4!RPC_INTERFACE::DispatchToStubWorker+0x18f 09 04e7fab4 75a03819 0300a178 00000000 00000000 rpcrt4!RPC_INTERFACE::DispatchToStub+0xeb 0a 04e7fb1c 759dbd13 04e7fb54 0300a0c0 0300fec0 rpcrt4!LRPC_SCALL::DispatchRequest+0x280a9 0b 04e7fba4 759d7335 030b7f50 030b6e48 00000000 rpcrt4!LRPC_SCALL::HandleRequest+0x383 0c 04e7fbf0 759d7c62 030b7f50 04e7fc68 030b6e48 rpcrt4!LRPC_ADDRESS::HandleRequest+0x2e5 0d 04e7fce4 759dfa98 00000000 03018a40 759df9f0 rpcrt4!LRPC_ADDRESS::ProcessIO+0x252 0e 04e7fd28 777e31c9 04e7fe60 0308ef04 03018a40 rpcrt4!LrpcIoComplete+0xa8 0f 04e7fd58 777e409f 04e7fe60 03018a40 00000000 ntdll!TppAlpcpExecuteCallback+0xa9 10 04e7ff4c 74288654 03043e78 74288630 73bd2ce2 ntdll!TppWorkerThread+0x81f 11 04e7ff60 77814a77 03043e78 2e81e9fe 00000000 kernel32!BaseThreadInitThunk+0x24 12 04e7ffa8 77814a47 ffffffff 77839ef5 00000000 ntdll!__RtlUserThreadStart+0x2f 13 04e7ffb8 00000000 777e3880 03043e78 00000000 ntdll!_RtlUserThreadStart+0x1b 0:002> ? 1d4c0 Evaluate expression: 120000 = 0001d4c0 The thread that is serving the request has called the Sleep function with the duration parameter set to 120000 msec.  

COM

The next set of wait types that WCT API can detect is COM. It can detect waits on both activation and method invocations. Waiting on COM activation I’ve created a simple COM object (WctActTest) and a COM+ Application (WctTestApp) that is hosting the WctActTest object. I’ve enabled object pooling and limited the maximum number of objects in the pool to be 5. The test is a short VBScript that creates 6 objects. After 5 objects are created and not released the COM+ infrastructure won’t allow the 6th activation request. Hence, the script host will wait. The “Analyze wait chain” UI shows the following Wait Chain for the wscript.exe: And, the corresponding entry in the WAITCHAIN log that is generated by WaitChain.exe is as follows: Process (0x3778:0n14200) - wscript.exe ---------------------------------- 28184: [3778:6e18:Blocked]->[Com:Owned:{b09cebcd-ba04-4c01-8927-b4122380c61d}]->[528:0:PidOnlyRpcss]->[ComActivation:Owned]->[5ee8:0:PidOnly]->[End] 9024: [3778:2340:Running]->[End] 31160: [3778:79b8:Running]->[End] 26232: [3778:6678:Running]->[End] 1712: [3778:6b0:Blocked]->[End] 11600: [3778:2d50:Running]->[End] 25832: [3778:64e8:Running]->[End] 30376: [3778:76a8:Blocked]->[End] 21164: [3778:52ac:Blocked]->[End] 11268: [3778:2c04:Blocked]->[End] Relevant Processes: 0x528->0x5ee8->0x3778->[END] It can be read as “The thread 6e18 (28184 in decimal) of process 3778 (14200 in decimal) is waiting on the COM object with ClassID {b09cebcd-ba04-4c01-8927-b4122380c61d}. The COM object is waiting to be activated. The activation request is delivered to the  process 528 (1320 in decimal, this is the RPCSS service). And, RPCSS is waiting on the process 5ee8 (24296 in decimal, dllhost.exe) that will do the activation”. “When a process calls CoGetClassObject or CoCreateInstance (CreateObject or new in VB) to activate a component, the COM runtime contacts its local SCM COM activator (RPCSS service) in order to launch the corresponding COM server  that will host the desired component. If the component is remote, the local RPCSS service will forward the request to the RPCSS service of the remote machine.” Therefore, RPCSS is involved. There is another entry called “Relevant Processes”. This is a list of the processes involved in the Wait Chains of the threads of the wscript.exe process.   Waiting on a COM method call In this case, there is a DCOM server process called WctComTest.exe and it is hosting a COM object with ProgID:wctCOM and ClassID: {5D74C767-00F4-400B-BE9F-11EA6F532AC2}. The COM object has a method that takes long time to finish execution. The client application that activates the wctCOM object and makes a method call on it is again a simple VBScript. Once more, the wscript.exe process is in focus as it is the waiting party. The "Analyze wait chain" UI shows the wait chain as follows : And, the corresponding entry in WaitChain.exe’s WAITCHAIN log file is: Process (0x63d4:0n25556) - wscript.exe ---------------------------------- 26872: [63d4:68f8:Blocked]->[Com:Owned]->[2840:2fdc:Blocked]->[End] 2752: [63d4:ac0:Blocked]->[End] 14620: [63d4:391c:Running]->[End] 29076: [63d4:7194:Running]->[End] 25908: [63d4:6534:Blocked]->[End] 10436: [63d4:28c4:Blocked]->[End] Relevant Processes: 0x2840->0x63d4->[END] This time the entry can be read as “The thread 68f8 (26872) of process 63d4 (25556 in decimal) is waiting on a COM method call that is executing on process 2840’s (10304 in decimal) thread 2fdc (12252 in decimal)”.  

Critical Sections

Critical sections can be used within a process for synchronization. It cannot be used to synchronize multiple processes. Hence, any output related to Critical Section in the WAITCHAIN log should be evaulated per process base. I have two test cases for Critical Section:
  • One is creating a deadlock
  • The other is the case where a thread has exited without leaving the entered critical section and another thread is waiting to enter that critical section
Deadlock In this classic case there are two threads and two critical sections. Each thread enters a critical section and then tries to enter the other critical section. Hence, an infinite wait. The “Analyze wait chain” UI has a precise explanation for the situation. The WAITCHAIN log has similar entries: Process (0x4540:0n17728) - SyncWaitTest.exe ---------------------------------- 22744: [4540:58d8:Blocked]->[End] 23712: [4540:5ca0:Blocked]->[End] 7896: [4540:1ed8:Blocked]->[CriticalSection:Owned]->[4540:39e0:Blocked]->[CriticalSection:Owned]->[4540:1ed8:Blocked]->[End] !!!Deadlock!!! 14816: [4540:39e0:Blocked]->[CriticalSection:Owned]->[4540:1ed8:Blocked]->[CriticalSection:Owned]->[4540:39e0:Blocked]->[End] !!!Deadlock!!! The first line is read as “Thread 1ed8 (7896 in decimal) waits on a critical section that is entered by the thread 39e0 (14816 in decimal) in the same process 4540 (17728 in decimal). And, thread 39e0 tries to enter to a critical section that is already entered by thread 1ed8. Hence, a deadlock.”. The other line in the report is similar. This time the Wait Chain for the thread 39e0 is listed therefore the order of the wait chain is reversed.   Waiting on an abandoned critical section Sometimes -usually due to – a thread that has entered to a critical section exits without leaving the critical section. If that is the case then any thread that is waiting on that critical section will wait forever. Because, there is no way for the already exited thread to leave that critical section anymore. This is a wait on an abandoned critical section. The WCT API reports this situation as follows:     The WAITCHAIN log has a very similar entry: Process (0x76b4:0n30388) - SyncWaitTest.exe ---------------------------------- 25960: [76b4:6568:Blocked]->[End] 23680: [76b4:5c80:Blocked]->[End] 29536: [76b4:7360:Blocked]->[CriticalSection:Abandoned]->[End] Since the WaitChain tool reports the type of the wait objects and their status the explanation is a bit more descriptive. Here the thread 7360 is waiting on an abandoned critical section. This requires further troubleshooting. Application Verifier can be used to break into debugger when a thread exists without leaving the critical sections that it has entered before.  

Mutual Exclusions (mutexes)

Mutexes are synchronization objects that can be used to synchronise more than one process. I’ve created a situation where one process acquires a mutex but does not release it. A second instance of that application tries to acquire the same mutex. However, the second instance will wait for the first process instance to release that mutex object.     The WAITCHAIN report will have the wait object type therefore a bit more information: Process (0x6524:0n25892) - SyncWaitTest.exe ---------------------------------- 13244: [6524:33bc:Blocked]->[End] 24676: [6524:6064:Blocked]->[End] Process (0x7b4c:0n31564) - SyncWaitTest.exe ---------------------------------- 13468: [7b4c:349c:Blocked]->[End] 19848: [7b4c:4d88:Blocked]->[Mutex:Owned:\Sessions\43\BaseNamedObjects\SyncWaitMutex]->[6524:6064:Blocked]->[End] Relevant Processes: 0x6524->[END]   The second instance of the SyncWaitTest.exe is waiting on a mutex named “SyncWaitMutex” that is acquired by the other instance of the SyncWaitTest.exe process.  

SendMessage

SendMessage is a blocking function. It can be cumbersome to figure out which window’s Windows Procedure is targeted. SPY++ and/or dump files are necessary. WCT API is very convenient in this case to find out the process that hosts the target window for the SendMessage call. To test the WCT API I’ve two applications:
  • One client application “SyncWaitTest.exe” that sends a message with MsgID : WM_USER+100 to the window whose class type is SampleWindowClass and window name is “LearntoProgramWindows”.
  • The SampleGUI.exe application which hosts this window will show a message box when that particular window message is received. Then it waits for the user to hit the OK button in the messagebox.
Until the OK button is clicked the SyncWaitTest.exe process’s thread which called the SendMessage API will wait. This how the “Analyze wait chain” UI reports it:   And, this is the content of the WAITCHAIN log: Process (0x3984:0n14724) - SyncWaitTest.exe ---------------------------------- 21768: [3984:5508:Blocked]->[SendMessage:Owned]->[36e4:66c:Blocked]->[End]   Once more the wait type inclusion gives further hints for the nature of the wait.  

Wait operations on processes and threads

WCT APIs can detect whether a thread is waiting on another thread to complete or a process to terminate. Let’s create a process (Notepad.exe) and wait for the termination of it. The “Analyze wait chain” UI shows it as follows:     And, it is listed in the WAITCHAIN log as follows: Process (0x597c:0n22908) - SyncWaitTest.exe ---------------------------------- 18568: [597c:4888:Blocked]->[End] 15796: [597c:3db4:Blocked]->[ProcWait:Owned]->[5ba8:0:PidOnly]->[End] Relevant Processes: 0x5ba8->[END]   Waiting on a thread has similar outcome. For the sake of completeness, I’m including the case of waiting on a thread. “Analyze wait chain” UI describes the situation as follows:   And, the WAITCHAIN log has the following information: Process (0x2e9c:0n11932) - SyncWaitTest.exe ---------------------------------- 21336: [2e9c:5358:Blocked]->[End] 29804: [2e9c:746c:Blocked]->[ThreadWait:Owned]->[2e9c:7894:Blocked]->[End] 30868: [2e9c:7894:Blocked]->[End]  

Caveat

I could not find a way through the WCT API to detect the Wait Chain of a thread that is waiting on multiple objects. E.g. assume a thread creates two notepad.exe instances and then waits on both of them to terminate. At that time the waiting thread’s callstack would look like this: 0:004> r;knL rax=000000000000005b rbx=0000000000000002 rcx=0000000000000002 rdx=0000004a040ffa80 rsi=0000000000000000 rdi=0000000000000002 rip=00007ff8263f09c4 rsp=0000004a040ff6b8 rbp=0000000000000000 r8=000001d784e9b230  r9=0000000000000000 r10=0000000000000000 r11=0000000000000246 r12=0000000000000008 r13=0000004a040ffa80 r14=0000000000000000 r15=0000000000000001 iopl=0         nv up ei pl zr na po nc cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246 ntdll!NtWaitForMultipleObjects+0x14: 00007ff8`263f09c4 c3              ret # Child-SP          RetAddr           Call Site 00 0000004a`040ff6b8 00007ff8`22faa966 ntdll!NtWaitForMultipleObjects+0x14 01 0000004a`040ff6c0 00007ff8`22faa84e KERNELBASE!WaitForMultipleObjectsEx+0x106 02 0000004a`040ff9c0 00007ff6`1fbb1e73 KERNELBASE!WaitForMultipleObjects+0xe 03 0000004a`040ffa00 00007ff8`26031fe4 SyncWaitTest!ChildProcesses+0x133 04 0000004a`040ffb10 00007ff8`263befb1 kernel32!BaseThreadInitThunk+0x14 05 0000004a`040ffb40 00000000`00000000 ntdll!RtlUserThreadStart+0x21 0:004> dq @rdx L2 0000004a`040ffa80  00000000`00000108 00000000`00000094 0:004> !handle 108 f;!handle 94 f Handle 0000000000000108 Type          Process Attributes    0 GrantedAccess 0x1fffff: Delete,ReadControl,WriteDac,WriteOwner,Synch Terminate,CreateThread,,VMOp,VMRead,VMWrite,DupHandle,CreateProcess,SetQuota,SetInfo,QueryInfo,SetPort HandleCount   8 PointerCount  294752 Name          <none> Object specific information Process Id  20376 Parent Process  20392 Base Priority 8 Handle 0000000000000094 Type          Process Attributes    0 GrantedAccess 0x1fffff: Delete,ReadControl,WriteDac,WriteOwner,Synch Terminate,CreateThread,,VMOp,VMRead,VMWrite,DupHandle,CreateProcess,SetQuota,SetInfo,QueryInfo,SetPort HandleCount   8 PointerCount  294634 Name          <none> Object specific information Process Id  24984 Parent Process  20392 Base Priority 8 However, nor “Analyze wait chain” nor WaitChain.exe does not reveal any clue.   Process (0x4fa8:0n20392) - SyncWaitTest.exe ---------------------------------- 18504: [4fa8:4848:Blocked]->[End] 31400: [4fa8:7aa8:Running]->[End] 28240: [4fa8:6e50:Running]->[End] 8200: [4fa8:2008:Running]->[End] 18716: [4fa8:491c:Blocked]->[End] Relevant Processes: 0x4fa8->[END]   Therefore, no reported Wait Chain does not always mean that a process is not waiting on any object.  

Conclusion

In case you want a tool that produces a report of all or specific processes' WaitChain lists, generate dump files of the processes showing up in those Wait Chains then feel free to download it from here WaitChain If you are interested in the source code then you are welcome to access it from here.   Enjoy!  ]]> Don't let your thread sleep unless it really has to https://docs.microsoft.com/archive/blogs/hmm/dont-let-your-thread-sleep-unless-it-really-has-to Thu, 26 Jan 2017 13:40:13 GMT https://blogs.msdn.microsoft.com/hmm/?p=165 Sleep . Remarks section is what needs to be understood thoroughly: “This function causes a thread to relinquish the remainder of its time slice and become unrunnable for an interval based on the value of dwMilliseconds. The system clock "ticks" at a constant rate. If dwMilliseconds is less than the resolution of the system clock, the thread may sleep for less than the specified length of time. If dwMilliseconds is greater than one tick but less than two, the wait can be anywhere between one and two ticks, and so on. To increase the accuracy of the sleep interval, call the timeGetDevCaps function to determine the supported minimum timer resolution and the timeBeginPeriod function to set the timer resolution to its minimum. Use caution when calling timeBeginPeriod, as frequent calls can significantly affect the system clock, system power usage, and the scheduler. If you call timeBeginPeriod, call it one time early in the application and be sure to call the timeEndPeriod function at the very end of the application. After the sleep interval has passed, the thread is ready to run. If you specify 0 milliseconds, the thread will relinquish the remainder of its time slice but remain ready. Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses.”   Hence:
  • The thread is not guaranteed to resume execution after dwMilliSeconds.
  • Abuse of the request for higher clock resolution might stress the system performance.
  Please read the experiences of developers in the discussion parts of the following forum articles: http://stackoverflow.com/questions/7614936/can-i-improve-the-resolution-of-thread-sleep https://social.msdn.microsoft.com/Forums/en-US/ed169c61-465a-40c9-a9ef-d5b0c6138fdc/how-to-increase-the-timer-resolution-for-threadsleep?forum=netfxbcl http://stackoverflow.com/questions/23215970/system-threading-timer-vs-system-threading-thread-sleep-resolution-net-timer   If your solution really requires a timer and you are not going to use it for polling then the following article might help you to understand more accurate timers : http://www.codeproject.com/Articles/1236/Timers-Tutorial What usually is suggested is to remove the call to the Sleep function and change the logic such that an alertable wait is used. E.g. insteadof waking up every 10 msec and checking a registry key’s some value register to the registry change event. This way the thread won’t waste any CPU cycles.   I’ve listed some of the blog entries of Raymond Chen about Sleep and Polling. He has already explained them very well. Please have a look before you design a solution around Sleep and Polling. Performance consequences of polling Consequences of the scheduling algorithm: Sleeping doesn’t always help Polling by sleeping versus polling by waiting with a timeout The dangers of sleeping on a UI thread Spurious wakes, race conditions, and bogus FIFO claims: A peek behind the curtain of WaitOnAddress The alertable wait is the non-GUI analog to pumping messages A thread waiting on a synchronization object could be caught napping When can a thread receive window messages? Hidden gotcha in the thread pool sample program on MSDN   Happy coding!]]> The curious case of a Windows Service consuming 3% of CPU time https://docs.microsoft.com/archive/blogs/hmm/the-curious-case-of-a-windows-service-consuming-3-of-cpu-time Wed, 09 Nov 2016 13:42:43 GMT https://blogs.msdn.microsoft.com/hmm/?p=156 0 days 7:54:01.000 Kernel time: 0 days 0:00:35.000 User time: 0 days 7:30:28.000   The output states that the process was running for 0 days, 7 hours, 54 minutes and 1 second. Also, the process has consumed 7 hours 31 minutes and 3 second processor time during its lifetime (Kernel Time + User Time). Let's convert both of the life and CPU-consumption times into seconds. Hence, we have 28441 for Up-Time and 27063 for CPU-Time. CPU-Time divided by Up-Time and multiplied by 100 will result into CPU utilization. This calculates a 95.15 % CPU utilization. But, in Task Manager each process's CPU usage is displayed as CPU usage with respect to all of the CPUs in the system. Hence, we need to learn the number of cores in this server. We get this information via the "!cupid" command. Let's do it : 0:000> !cpuid CP  F/M/S  Manufacturer     MHz 0  6,13,7  <unavailable>   2700 1  6,13,7  <unavailable>   2700 2  6,13,7  <unavailable>   2700 3  6,13,7  <unavailable>   2700 4  6,13,7  <unavailable>   2700 5  6,13,7  <unavailable>   2700 6  6,13,7  <unavailable>   2700 7  6,13,7  <unavailable>   2700 8  6,13,7  <unavailable>   2700 9  6,13,7  <unavailable>   2700 10  6,13,7  <unavailable>   2700 11  6,13,7  <unavailable>   2700 12  6,13,7  <unavailable>   2700 13  6,13,7  <unavailable>   2700 14  6,13,7  <unavailable>   2700 15  6,13,7  <unavailable>   2700 16  6,13,7  <unavailable>   2700 17  6,13,7  <unavailable>   2700 18  6,13,7  <unavailable>   2700 19  6,13,7  <unavailable>   2700 20  6,13,7  <unavailable>   2700 21  6,13,7  <unavailable>   2700 22  6,13,7  <unavailable>   2700 23  6,13,7  <unavailable>   2700 24  6,13,7  <unavailable>   2700 25  6,13,7  <unavailable>   2700 26  6,13,7  <unavailable>   2700 27  6,13,7  <unavailable>   2700 28  6,13,7  <unavailable>   2700 29  6,13,7  <unavailable>   2700 30  6,13,7  <unavailable>   2700 31  6,13,7  <unavailable>   2700 There are 32 cores in the computer. A 100% CPU usage of a single core by a process would be showed in the CPU column in Task Manager as 1 / 32 x 100. This equals to 3.125%. However, in this case the service process consumes roughly 95.15% of a single core. Then, we need to find out the 95.15 percent of 3.125. And, this is 3,125 x 0,9515 = 2,9734. Which might be rounded up as 3 % in Task Manager. This leaves us with the probability of one thread of the process being in a tight loop. Let's verify. The "!runaway" command lists the threads of a process and their CPU usage time. The list contains only the threads those are running at the time when the dump was generated. It does not contain any thread that has executed and exited before the dump was made. 0:000> !runaway User Mode Time Thread       Time   89:e370      0 days 7:29:37.128 34:3fc0      0 days 0:00:05.304 45:9b20      0 days 0:00:02.636 84:8830      0 days 0:00:00.546 93:21340      0 days 0:00:00.390 91:1b3f4      0 days 0:00:00.265 94:21264      0 days 0:00:00.234 59:179f4      0 days 0:00:00.234 75:1edc4      0 days 0:00:00.218 68:20aec      0 days 0:00:00.218 [Truncated the complete output for brevity] The top consumer is the thread with Debugger ID 89. It has used 7 hours 29 minutes and 37 seconds of CPU time. This is almost equal to the total CPU usage time of the process. Let's switch to that thread : 0:089> ~89s XYZ_ABC_PQR!XYZ.ABC.PQR.ResourcePool.PoolManagerFunc()+0xb4: 000007fe`99834b14 85c0            test    eax,eax and see what it is doing : 0:089> !clrstack -n OS Thread Id: 0xe370 (89) Child SP               IP Call Site 0000000023d2e590 000007fe99834b14 XYZ_ABC_PQR!XYZ.ABC.PQR.ResourcePool.PoolManagerFunc() 0000000023d2e5f0 000007fe99543cb5 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) 0000000023d2e750 000007fe995408b9 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) 0000000023d2e780 000007fe995407ef System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) 0000000023d2e7d0 000007fe9953c130 System.Threading.ThreadHelper.ThreadStart() 0000000023d2eb38 000007fef8739e03 [GCFrame: 0000000023d2eb38] 0000000023d2ee68 000007fef8739e03 [DebuggerU2MCatchHandlerFrame: 0000000023d2ee68] 0000000023d2f048 000007fef8739e03 [ContextTransitionFrame: 0000000023d2f048] 0000000023d2f238 000007fef8739e03 [DebuggerU2MCatchHandlerFrame: 0000000023d2f238] There is no function name that suggests any wait. Hence, the thread should be spinning inside XYZ_ABC_PQR!XYZ.ABC.PQR.ResourcePool.PoolManagerFunc(). We need to understand what this function is doing. Let's find the module information first : 0:089> lm start             end                 module name 00000000`69370000 00000000`693b0000   XYZ_ABC_PQR C (no symbols) [Truncated the complete output for brevity]   And, then write the module into a file. 0:089> !savemodule 00000000`69370000 F:\work\blog\modules\XYZ.ABC.PQR.dll 3 sections in file section 0 - VA=2000, VASize=38904, FileAddr=200, FileSize=38a00 section 1 - VA=3c000, VASize=3d0, FileAddr=38c00, FileSize=400 section 2 - VA=3e000, VASize=c, FileAddr=39000, FileSize=200   Finally, open the saved module XYZ.ABC.PQR.dll within ILSpy (or any .NET reflector tool) and browse the PoolManagerFunc :

private static void PoolManagerFunc() { while (ResourcePool.Initialized) { if (ResourcePool.availableResources.Count <= ResourcePool.POOL_MIN_SIZE) { // Open a resource and add it to the pool. Then, sleep for 50 milliseconds. Removed the actual code! Thread.Sleep(50); } } }

The code above suggests that if the number of resources in the pool is less than the configured minimum then create a new resource and add it to the pool. However, if there are at least a minimum number of resources in the pool then the loop "while (ResourcePool.Initialized)" and the control statement "if (ResourcePool.availableResources.Count <= ResourcePool.POOL_MIN_SIZE)" are executed all the time. To have an idea of the number of resources in that pool we simply need to dump out the ResourcePool class instance. Since, that class instance is declared as static we have to dump it with the  command "!dumpclass". Before that we have to find out the class address of XYZ.ABC.PQR.ResourcePool. We will first learn the MethodTable value using the XYZ.ABC.PQR.ResourcePool.PoolManagerFunc function. Let's re-visit the following output : 0:089> !clrstack -n OS Thread Id: 0xe370 (89) Child SP               IP Call Site 0000000023d2e590 000007fe99834b14 XYZ_ABC_PQR!XYZ.ABC.PQR.ResourcePool.PoolManagerFunc() [Truncated the complete output for brevity] Asking the SOS extension the MethodDescriptor value of the IP (Instruction Pointer) : 0:089> !ip2md 000007fe99834b14 MethodDesc:   000007fe998e80c0 Method Name:  XYZ.ABC.PQR.ResourcePool.PoolManagerFunc() Class:        000007fe99912808 MethodTable:  000007fe998e8140 mdToken:      00000000060001d3 Module:       000007fe998e2220 IsJitted:     yes CodeAddr:     000007fe99834a60 Transparency: Critical So the class address is 000007fe99912808. 0:089> !dumpclass 000007fe99912808 Class Name:      XYZ.ABC.PQR.ResourcePool mdToken:         0000000002000091 File:            C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\www\c2274130\f70100df\assembly\dl3\0d903943\00c83a5a_1060d101\XYZ.ABC.PQR.ResourcePool.dll Parent Class:    000007fe990f9730 Module:          000007fe998e2220 Method Table:    000007fe998e8140 Vtable Slots:    4 Total Method Slots:  5 Class Attributes:    181  Abstract, Transparency:        Critical NumInstanceFields:   0 NumStaticFields:     b MT    Field   Offset                 Type VT     Attr            Value Name [Truncated the complete output for brevity] 000007fe998e81d0  400085f      110 XYZ.ABC.PQR]]  0   static 00000006bf2e6880 availableResources 000007fe990df9e8  4000862       f4         System.Int32  1   static               20 POOL_MIN_SIZE 000007fe990df9e8  4000863       f8         System.Int32  1   static              500 POOL_MAX_SIZE 000007fe990dc918  4000865      101       System.Boolean  1   static                1 Initialized   Then dump the "availableResources" member's content : 0:089> !DumpObj 00000006bf2e6880 Name:        System.Collections.Generic.Queue`1[[XYZ.ABC.PQR.CustomResource, XYZ.ABC.PQR]] MethodTable: 000007fe998e81d0 EEClass:     000007fe9990e458 Size:        48(0x30) bytes File:        C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll Fields: MT    Field   Offset                 Type VT     Attr            Value Name 000007fe990dbd20  40007fa        8      System.Object[]  0 instance 000000083f30bbe0 _array 000007fe990df9e8  40007fb       18         System.Int32  1 instance                1 _head 000007fe990df9e8  40007fc       1c         System.Int32  1 instance               23 _tail 000007fe990df9e8  40007fd       20         System.Int32  1 instance               22 _size 000007fe990df9e8  40007fe       24         System.Int32  1 instance           108510 _version 000007fe990d63a8  40007ff       10        System.Object  0 instance 0000000000000000 _syncRoot 000007fe990dbd20  4000800        8      System.Object[]  0   static  <no information> Hence, there are currently 22 resources in the pool. The code fragment that is responsible for new resource creation, pool addition and sleeping will only execute if the number of resources drops below the minimum (which is 20, right now) else the whole time the thread will execute a tight loop. And, that will cause the 3% CPU usage. To fix the problem the implementation of XYZ.ABC.PQR.ResourcePool.PoolManagerFunc() should be changed such that a new resource is added when the number of resources drops below the lower threshold and not polling the number of resources in a tight loop. Good luck!   REFERENCES .time (Display System Time) !cupid !runaway SOS.dll (SOS Debugging Extension) How to create a user-mode process dump file in Windows Vista and in Windows 7    ]]> General Troubleshooting Reference https://docs.microsoft.com/archive/blogs/hmm/general-troubleshooting-reference Sat, 08 Oct 2016 16:08:13 GMT https://blogs.msdn.microsoft.com/hmm/?p=155 ONLINE KNOWLEDGE RESOURCES TOOLS BOOKS  

ONLINE KNOWLEDGE RESOURCES

The following resources are from Mark Russinovich. There are videos, blogs and various online resouces. The topics are around troubleshooting different problems using Mark's tools. Some resources dive deep into the Windows Operating System. Sysinternals Learning Resources https://technet.microsoft.com/en-us/sysinternals/bb469930   Windows Sysinternals Administrator's Reference https://technet.microsoft.com/en-us/sysinternals/hh290819   Mark's Webcasts https://technet.microsoft.com/en-us/sysinternals/bb963887   Mark's Blog https://blogs.technet.microsoft.com/markrussinovich/   The following is a very useful set of episodes on Channel 9. Each episode is about a different topic. It is basically around troubleshooting very different scenarios with a wide range of tools. It is highly probable that you encounter an episode that matches your current ongoing issue whatever that might be :)   Defrag Tools https://channel9.msdn.com/Shows/Defrag-Tools
Microsoft Blogs about Windows Technologies and Support
  Windows Supportability Team Blog https://blogs.technet.microsoft.com/supportingwindows/   Ask the Core Team / Microsoft Enterprise Platforms Support: Windows Server Core Team https://blogs.technet.microsoft.com/askcore/   Ask the Directory Services Team / Microsoft's official enterprise support blog for AD DS and more https://blogs.technet.microsoft.com/askds/   Ask Premier Field Engineering (PFE) Platforms https://blogs.technet.microsoft.com/askpfeplat/   Ntdebugging Blog / Microsoft Advanced Windows Debugging and Troubleshooting https://blogs.msdn.microsoft.com/ntdebugging/   Networking Blog / Windows Networking support team and Product team blog https://blogs.technet.microsoft.com/networking/   Clustering and High-Availability / Failover Clustering and Network Load Balancing Team Blog https://blogs.msdn.microsoft.com/clustering/   Server Storage at Microsoft / The official blog of the Windows Server storage engineering teams https://blogs.technet.microsoft.com/filecab/   The Hot Blog / In hot blog, we blog hotfix right! https://blogs.technet.microsoft.com/hot/   Microsoft Edge Developer https://blogs.windows.com/msedgedev   IEBlog / Internet Explorer Team Blog https://blogs.msdn.microsoft.com/ie/  
Measuring Application Performance
  Improving Your App’s Performance with PerfView https://blogs.msdn.microsoft.com/dotnet/2012/10/09/improving-your-apps-performance-with-perfview/   Vance Morrison's Weblog https://blogs.msdn.microsoft.com/vancem/tag/perfview/   PerfView Tutorial https://channel9.msdn.com/Series/PerfView-Tutorial   Microsoft/perfview https://github.com/Microsoft/perfview    

TOOLS

  Sysinternals Utilities Index https://technet.microsoft.com/en-us/sysinternals/bb545027   PerfView https://www.microsoft.com/en-us/download/details.aspx?id=28567   PerfView is a performance-analysis tool that helps isolate CPU- and memory-related performance issues. PerfView Tutorial is a multipart series that can be found at : https://channel9.msdn.com/Series/PerfView-Tutorial   The source code can be downloaded from Microsoft/perfview https://github.com/Microsoft/perfview   Windows Performance Toolkit https://msdn.microsoft.com/en-us/windows/hardware/commercialize/test/wpt/index   Dependency Walker 2.2 http://www.dependencywalker.com/    

BOOKS

  Troubleshooting with the Windows Sysinternals Tools (2nd Edition) 2nd Edition https://www.amazon.com/Troubleshooting-Windows-Sysinternals-Tools-2nd/dp/0735684448/ref=pd_bxgy_14_img_2?ie=UTF8&psc=1&refRID=ESPM5ZENR3JX7QBCPZ7Z   Windows Performance Analysis Field Guide https://www.amazon.com/gp/product/0124167012/ref=pd_sim_14_4?ie=UTF8&pd_rd_i=0124167012&pd_rd_r=HNRWPWPPXDW1H86RX9CF&pd_rd_w=yQWRM&pd_rd_wg=fXuFA&psc=1&refRID=HNRWPWPPXDW1H86RX9CF   Windows Internals, Part 1 (6th Edition) (Developer Reference) 6th Edition https://www.amazon.com/Windows-Internals-Part-Developer-Reference/dp/0735648735/ref=sr_1_2?ie=UTF8&qid=1475941683&sr=8-2&keywords=windows+internals   Windows Internals, Part 2 (6th Edition) (Developer Reference) 6th Edition https://www.amazon.com/Windows-Internals-Part-Developer-Reference/dp/0735665877/ref=sr_1_3?ie=UTF8&qid=1475941683&sr=8-3&keywords=windows+internals]]> Trace.WriteLine may call OutputDebugString https://docs.microsoft.com/archive/blogs/hmm/trace-writeline-may-call-outputdebugstring Sun, 17 May 2015 02:52:00 GMT https://blogs.msdn.microsoft.com/hmm/2015/05/17/trace-writeline-may-call-outputdebugstring/ Recently, I was asked to check a couple of dump files. They were generated when their Biztalk server process was responding slow. I’ve listed the callstacks of all the threads. More than 100 threads were waiting to enter a monitor. An example callstack of such waiting threads is as follows :

 

System.Threading.Monitor.Enter(System.Object)

System.Diagnostics.TraceInternal.WriteLine(System.String)                          

XYZ.BiztalkESB.Utilities.GenericHelper.TraceWrite(System.String, System.String, System.String)

XYZ.BiztalkESB.Utilities.CacheBase.TryGetValue

XYZ.BiztalkESB.Utilities.InterchangeParameterCache.GetParamValue

XYZ.BiztalkESB.Utilities.ParameterHelper.GetInterchangeParameter

XYZ.BiztalkESB.Utilities.LoggerHelper.Log

XYZ.BiztalkESB.Utilities.LoggerHelper.LogHeader

XYZ.SomeIntegration.Biztalk.Resolvers.InterchangeDefinitionResolverOnline.Resolve

XYZ.BiztalkESB.Resolvers.XYZSomeResolveProvider.ResolveItineraryName

XYZ.BiztalkESB.Resolvers.XYZSomeResolveProvider.Resolve

Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve

Microsoft.Practices.ESB.Itinerary.PipelineComponents.ItinerarySelector.Execute

Microsoft.BizTalk.Internal.ComponentWrapper.Execute

Microsoft.BizTalk.PipelineOM.SimpleStage.Execute

Microsoft.BizTalk.PipelineOM.Pipeline.Execute

Microsoft.BizTalk.PipelineOM.ReceivePipeline.GetNext

 

And, the thread that has entered the monitor has the following callstack. This thread is waiting while executing OutputDebugString.

 

ntdll!ZwWaitForSingleObject+0xa

KERNELBASE!WaitForSingleObjectEx+0x92

KERNELBASE!WaitForSingleObject+0xd

KERNELBASE!OutputDebugStringA+0x130

KERNELBASE!OutputDebugStringW+0x58

System_ni!DomainNeutralILStubClass.IL_STUB_PInvoke(System.String)+0x82

System_ni!System.Diagnostics.DefaultTraceListener.Write(System.String, Boolean)+0x41

System_ni!System.Diagnostics.DefaultTraceListener.WriteLine(System.String, Boolean)+0x3f

System_ni!System.Diagnostics.TraceInternal.WriteLine(System.String)+0xfb

XYZ_BiztalkESB_Utilities!XYZ.BiztalkESB.Utilities.GenericHelper.TraceWrite(System.String, System.String, System.String)+0x59

XYZ_BiztalkESB_Utilities!XYZ.BiztalkESB.Utilities.CacheBase.TryGetValue

XYZ_BiztalkESB_Utilities!XYZ.BiztalkESB.Utilities.InterchangeParameterCache.GetParamValue

XYZ_BiztalkESB_Utilities!XYZ.BiztalkESB.Utilities.ParameterHelper.GetInterchangeParameter

XYZ_BiztalkESB_Utilities!XYZ.BiztalkESB.Utilities.LoggerHelper.Log

XYZ_BiztalkESB_Utilities!XYZ.BiztalkESB.Utilities.LoggerHelper.LogHeader

XYZ_SomeIntegration_Biztalk_Resolvers!XYZ.XYZSomeIntegration.Biztalk.Resolvers.InterchangeDefinitionResolverOnline.Resolve

XYZ_BiztalkESB_Resolvers!XYZ.BiztalkESB.Resolvers.XYZSomeResolveProvider.ResolveItineraryName

XYZ_BiztalkESB_Resolvers!XYZ.BiztalkESB.Resolvers.XYZSomeResolveProvider.Resolve

Microsoft_Practices_ESB_Resolver!Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve

 

It is time to use http://referencesource.microsoft.com Let’s first understand why a monitor is used. In the source of TraceInternal.WriteLine we can clearly see the synchronisation part :

 

public static void WriteLine(string message) {

 if (UseGlobalLock)
  {

  lock (critSec)
  {

   foreach (TraceListener listener in Listeners)
  {

    listener.WriteLine(message);

    if (AutoFlush)
  listener.Flush();}}

[The rest is truncated]

 The lock is defined as :

 internal static readonly object critSec = new object();

 

 

Also, we understand that once the monitor is available then a listener’s WriteLine method is called. From the callstack of the thread that entered into the monitor we see that the DefaultListener is used. And, an internal version is called :

 

void internalWrite(string message) {

 if (Debugger.IsLogging())
  {

  Debugger.Log(0, null, message);

  }

  else
  {

       if (message == null)

        SafeNativeMethods.OutputDebugString(String.Empty);           

       else

        SafeNativeMethods.OutputDebugString(message);
         } }

 

If there is no debugger attached to the process (we knew that there was no debugger attached to Biztalk server) then OutputDebugString is called. This explains the “OutputDebugString” in callstack of the waiting threads. Next, we need to understand what the OutputDebugString is waiting on. If we examine the parameters of the WaitForSingleObject we will see that an event called DBWIN_BUFFER_READY ( E.g. \Sessions\<SessionNo>\BaseNamedObjects\DBWIN_BUFFER_READY) for 10 seconds. Now, the problem has  changed a bit. Why a string sent to OutputDebugString is processed for so long? Well we know that no debuggers are attached to the Biztalk process. Then what happens to the debug string?

We need to find out how OutputDebugString works. If you search on internet for DBWIN_BUFFER_READY you will find many examples. And, if you still have the Visual Studio 6 SDK which has the DBMon sample (https://msdn.microsoft.com/en-us/library/aa242171(v=vs.60).aspx ) then you’ll see how that string is consumed.

The string is put to a memory mapped file named “DBWIN_BUFFER”. Once the string is put an event named “DBWIN_DATA_READY” is signalled. The party that is waiting on that event will consume that memory mapped file’s content. That party is another application which does not have to be a debugger at all. E.g. the DBMon sample application is perfectly capable to consume the debug string. Once the memory mapped file’s content is consumed then the DBWIN_DATA_READY is set and another event called “DBWIN_BUFFER_READY” is signalled. Now, the application that calls OutputDebugString can continue. Meanwhile, if the consumer application cannot process the content within 10 seconds then OutputDebugString returns.

If that is the case and a fair lock is used and there are 100 threads waiting on the Trace.WriteLine function’s monitor then the last thread would wait for 10x100 seconds. Roughly 16 min. The experience will  ofcourse be a slow system. Just like my customer has felt. Let’s move on. Which application it was in our case that acted as the consumer of  OutputDebugString? The answer is DebugView. So how come DebugView did process the strings so slowly? The answer is “History Depth”. This option was not set in DebugView. If not set then all of the previous debug strings are kept. This causes the list view to operate considerably slower if there is a chatty environment in terms of OutputDebugStrings. Hence, if you want to use DebugView then you better set the History Depth.

Have a great day!

faik hakan bilgen

]]> Unable to read handle information https://docs.microsoft.com/archive/blogs/hmm/unable-to-read-handle-information Fri, 15 May 2015 23:24:00 GMT https://blogs.msdn.microsoft.com/hmm/2015/05/15/unable-to-read-handle-information/  

The easiest way to generate a dump file is using Task Manager. All you have to do is to find the correct process

and then right click on it and choose the “Create dump file” menu item. When you start working on a dump file sooner

or later you might want to check the handles. In that case you receive the following response :

0:000>!handle

ERROR:
!handle: extension exception 0x80004002.

    "Unable to read handle information"

 

Not all dump files have the handle information of a process. There is a way to see whether the handle data is included or not in the dump file.

0:000>.dumpdebug

----- User
Mini Dump Analysis

 

MINIDUMP_HEADER:

Version         A793 (6380)

NumberOfStreams 11

Flags           1826

                0002 MiniDumpWithFullMemory

                0004 MiniDumpWithHandleData

                0020 MiniDumpWithUnloadedModules

                0800 MiniDumpWithFullMemoryInfo

                1000 MiniDumpWithThreadInfo

 

Voila! The dump file should have the handle information. For details of different dump types you can check the following references.

 

MINIDUMP_TYPE enumeration

https://msdn.microsoft.com/en-us/library/windows/desktop/ms680519(v=vs.85).aspx

 

MiniDumpWithHandleData

Include high-level information about the operating system handles that are active when the minidump is made.

 

So far so good. However, the reason for not having the handle information is an issue with Task Manager.

With current releases of Windows 10 RC and Windows Server RC editions you can see that Task Manager includes the handle data in the dump files.

Until Windows 10 is RTMed and widespread we can generate dump files with usual ways if we are after the handle information.

 

HTH

-faik

]]> Dump Dosyası İncelemeye Giriş https://docs.microsoft.com/archive/blogs/hmm/dump-dosyas-ncelemeye-giri Fri, 15 May 2015 03:30:40 GMT https://blogs.msdn.microsoft.com/hmm/2015/05/15/dump-dosyas-ncelemeye-giri/ Merhaba,
Uzun bir aradan sonra debugging ile ilgili serime devam ediyorum. Artık dump dosyalarını nasıl inceleyeceğimize geçeceğiz. Dump Alma ( Hang Mode - I ) yazımdaki yöntemle yanıt vermeyen bir uygulamanın dump'ını aldığınızı farz ediyorum.

Start –> All Programs –> Debugging Tools for Windows(x86) –> WinDbg uygulamasını açın.
File menüsünden “Open Crash Dump” seçeneğini tıklayın. Açılan gezgin penceresinden daha önce oluşturduğunuz dmp uzantılı dosyayı bulun ve açın.
“Save information for workspace” sorusunu her zaman hayır olarak yanıtlayın.

Biraz bekledikten sonra aşağıdaki gibi bir çıktı alacaksınız :

Debugger’ın Versiyon bilgisi :
Microsoft (R) Windows Debugger Version 6.13.0003.956 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Yüklenen dump dosyasının yeri ve adı :
Loading Dump File [H:\BLOG\dumps\20101229_112225_Hang_Mode\FULLDUMP_HangMode_UITest.exe__061c_2010-12-29_11-22-28-575_158c.dmp]

Dump dosyasının tipi :
User Mini Dump File with Full Memory: Only application data is available
Comment: 'HangMode'

Sembol bilgileri :
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:

Debugging, doğru sembol dosyaları olmadan çok zor yapılabilir çünkü; nerdeyse herşeyi disassemble edilmiş koddan bulmaya çalışırsınız.
Aşağıdaki bölümlerde konuyu daha fazla ele alacağım. Şu kadarını hatırlamanız yeterli : Sembol dosyası olmadan debugging yapılmaz.

Dump’ın alındığı makina ve sistem bilgileri :
Windows 7 Version 7600 MP (2 procs) Free x86 compatible
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 6.1.7600.16385 (win7_rtm.090713-1255)
Machine Name:
Debug session time: Wed Dec 29 11:22:28.000 2010 (UTC + 2:00)
System Uptime: 6 days 18:34:10.924
Process Uptime: 0 days 0:40:35.000

Bu bilgiler işinize yarayabilir. İşletim Sisteminin sürümü, makina adı, dump'ın ne zaman alındığı. Bu bilgileri kullanarak Sistem ve Uygulama günlüklerini kontrol edebilirsiniz.
Yakın zamanda herhangi bir problem olup olmadığını denetleyebilirsiniz. Sistem ve Proses'in ne kadar zamandır çalıştığı da bir fikir verebilir. Sorunun sıklığına dair fikir edinebilirsiniz.

Sembol uyarıları ve exception bilgisi :

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll -
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(158c.14f8): Wake debugger - code 80000007 (first/second chance not available)

Debugger (invasive moddayken) process'te bir thread yaratır ve DebugBreak fonksiyonunu çağırır. Bu da process'in
breakpoint exception'ı vermesine sebep olur. Dolayısıyla hang modda alınmış dump dosyalarında 0x80000007 numaralı olayın olması normal.

Şu anda debugger context’inin set edildiği thread’in register bilgileri :

eax=00000000 ebx=0022f2bc ecx=00000000 edx=00000000 esi=00000002 edi=00000000
eip=77b300ed esp=0022f26c ebp=0022f308 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!NtWaitForMultipleObjects+0x15:
77b300ed 83c404          add     esp,4

WinDbg ekranının sol alt köşesinde "0:000>" ibaresini göreceksiniz. Aslında bu ProcessID:ThreadID ikilisini gösterir. User mode dumplarda ProcessID hep 0 olacaktır.
Dolayısıyla gördüğünüz "0:000", bu process'in 0 numaralı thread'inde olduğunuzu ifade eder. Kernel dumplarında Process Context'ini değiştirebilirsiniz.
ProcessID:ThreadID metin kutusunun sağında yer alan metin editör kontrolünü kullanarak WinDbg'ye istediğimiz komutları yollayacağız.

 

 

 

İlk komutlar


Dumpı alınmış process'in kaç tane thread'i olduğuna bakalım.
0:000> yazan kısımın sağ tarfındaki textbox'ı kullanacağız.
~ yazın ve enter'a basın
Aşağıdakine benzer bir çıktı alacaksınız.

0:000> ~
.  0  Id: 158c.14f8 Suspend: 1 Teb: 7efdd000 Unfrozen
   1  Id: 158c.104c Suspend: 1 Teb: 7efda000 Unfrozen
   2  Id: 158c.a1c Suspend: 1 Teb: 7efd7000 Unfrozen

Bu çıktı bize process içinde 3 thread olduğunu gösteriyor : 0, 1 ve 2. threadler. Windbg, thread'leri 0 dan başlayarak numaralandırır. Ayrıca, gerçek numaralarını da gösterir.
Örneğin, 158c.14f8 bize thread'in 158c ProcessID'li process'in 14f8 numaralı thread'i olduğunu anlatıyor. Teb: 7efdd000 ise TEB veri yapısının adresini gösterir.

CreateThread Function , TEB Structure 

Bir thread'in call stack'ini listelemek
Bu kez komut penceresine ( ProcessID:ThreadID metin kutusunun sağında yer alan metin editör kontrolü ) k komutunu girip enter'a basın.
Aşağıdakine benzer bir çıktı ile karşılaşacaksınız.

0:000> k
ChildEBP RetAddr 
WARNING: Stack unwind information not available. Following frames may be wrong.
0022f308 7614162d ntdll!NtWaitForMultipleObjects+0x15
0022f350 76141921 kernel32!WaitForMultipleObjectsEx+0x8e
0022f36c 65aa10e2 kernel32!WaitForMultipleObjects+0x18
0022f3b0 00d41b1d Senaryolar!DeadLockDurumuYarat+0x82
0022f3bc 61e42c6f UITest+0x1b1d
0022f3c8 61e42e51 mfc100u+0x1b2c6f
0022f3e4 61e76d36 mfc100u+0x1b2e51
0022f408 61ecc444 mfc100u+0x1e6d36
0022f458 61d0cceb mfc100u+0x23c444
0022f46c 61ecbc47 mfc100u+0x7cceb
0022f538 61ecbbba mfc100u+0x23bc47
0022f558 61eca019 mfc100u+0x23bbba
0022f5d0 61eca2a5 mfc100u+0x23a019
0022f5f4 61dc0ddb mfc100u+0x23a2a5
0022f63c 774a6238 mfc100u+0x130ddb
0022f668 774a68ea user32!gapfnScSendMessage+0x270
0022f6e0 774acd1a user32!gapfnScSendMessage+0x922
0022f724 774acd81 user32!GetWindow+0x21a
0022f748 74354e95 user32!SendMessageW+0x4c
0022f768 74354ef7 comctl32!GetEffectiveClientRect+0x306c
0022f784 74354d89 comctl32!GetEffectiveClientRect+0x30ce
0022f7e4 774a6238 comctl32!GetEffectiveClientRect+0x2f60
0022f810 774a68ea user32!gapfnScSendMessage+0x270
0022f888 774a7d31 user32!gapfnScSendMessage+0x922
0022f8e8 774a7dfa user32!LoadStringW+0x11f
0022f8f8 774c2292 user32!DispatchMessageW+0xf
0022f924 61ee0ac0 user32!IsDialogMessageW+0x11e
0022f938 61eced28 mfc100u+0x250ac0
0022f944 61e6c3ad mfc100u+0x23ed28
0022f99c 61d0cc9c mfc100u+0x1dc3ad
0022f9ac 61eccec5 mfc100u+0x7cc9c
0022f9c0 61eb8a28 mfc100u+0x23cec5
0022f9d8 61eb922d mfc100u+0x228a28
0022f9e4 61eb8a78 mfc100u+0x22922d
0022f9f0 61eb895d mfc100u+0x228a78
0022fa2c 61e6cae3 mfc100u+0x22895d
0022fa78 00d41197 mfc100u+0x1dcae3
0022fbfc 61ede3c3 UITest+0x1197
0022fc10 00d42425 mfc100u+0x24e3c3
0022fca4 76143677 UITest+0x2425
0022fcb0 77b49d42 kernel32!BaseThreadInitThunk+0x12
0022fcf0 77b49d15 ntdll!RtlInitializeExceptionChain+0x63
0022fd08 00000000 ntdll!RtlInitializeExceptionChain+0x36

Dikkat edilmesi gerekenler :
"WARNING: Stack unwind information not available. Following frames may be wrong." mesajı bize debugger'ın sembol dosyalarını bulamadığını o yüzden
callstack'i düzgün çıkaramadığını söylüyor.

Sembol dosyalarına erişmek :

Debugger'ın, sembol dosyalarına erişimini anlatan temel makaleyi okuyabilirsiniz :
Use the Microsoft Symbol Server to obtain debug symbol files

Adım adım ayarların yapılması :
#1 Bilgisayarınızda bir dizin açın. Bu dizin debugger'ın indirdiği sembol dosyalarını tutacaktır.
Örneğin :
H:\BLOG\symbols

#2 Windbg'de "File" menüsünden "Symbol File Path" seçeneğini tıklayın. Açılan pencere içine aşağıdakileri girin :
SRV*H:\BLOG\symbols*http://msdl.microsoft.com/download/symbols

Not : Sizin lokal sembol cache dizininiz farklı olabilir. Bu durumda "H:\BLOG\symbols" yerine o dizini girin.

#3 "Reload" checkbox'ını işaretleyin ve "OK" butonuna basın.

Şimdi k komutunu tekrar çalıştırın. Bu kez oldukça farklı bir callstack göreceksiniz :

0:000> k
ChildEBP RetAddr 
0022f26c 75b30962 ntdll!ZwWaitForMultipleObjects+0x15
0022f308 7614162d KERNELBASE!WaitForMultipleObjectsEx+0x100
0022f350 76141921 kernel32!WaitForMultipleObjectsExImplementation+0xe0
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for Senaryolar.dll -
0022f36c 65aa10e2 kernel32!WaitForMultipleObjects+0x18
*** ERROR: Module load completed but symbols could not be loaded for UITest.exe
WARNING: Stack unwind information not available. Following frames may be wrong.
0022f3b0 00d41b1d Senaryolar!DeadLockDurumuYarat+0x82
0022f3bc 61e42c6f UITest+0x1b1d
0022f3c8 61e42e51 mfc100u!_AfxDispatchCmdMsg+0x3b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 82]
0022f3e4 61e76d36 mfc100u!CCmdTarget::OnCmdMsg+0x124 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 381]
0022f408 61ecc444 mfc100u!CPropertySheet::OnCmdMsg+0x1d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgprop.cpp @ 814]
0022f458 61d0cceb mfc100u!CWnd::OnCommand+0x92 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2675]
0022f46c 61ecbc47 mfc100u!CDialogEx::OnCommand+0x2f [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxdialogex.cpp @ 290]
0022f538 61ecbbba mfc100u!CWnd::OnWndMsg+0x66 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2081]
0022f558 61eca019 mfc100u!CWnd::WindowProc+0x24 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2067]
0022f5d0 61eca2a5 mfc100u!AfxCallWndProc+0xb5 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 248]
0022f5f4 61dc0ddb mfc100u!AfxWndProc+0x37 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 410]
0022f634 774a6901 mfc100u!AfxWndProcBase+0x56 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp @ 420]
0022f6e0 774acd1a user32!UserCallWinProcCheckWow+0x120
0022f724 774acd81 user32!SendMessageWorker+0x581
0022f748 74354e95 user32!SendMessageW+0x7f
0022f768 74354ef7 comctl32!Button_NotifyParent+0x3d
0022f784 74354d89 comctl32!Button_ReleaseCapture+0x113
0022f7e4 774a6238 comctl32!Button_WndProc+0xa18
0022f810 774a68ea user32!InternalCallWinProc+0x23
0022f888 774a7d31 user32!UserCallWinProcCheckWow+0x109
0022f8e8 774a7dfa user32!DispatchMessageWorker+0x3bc
0022f8f8 774c2292 user32!DispatchMessageW+0xf
0022f924 61ee0ac0 user32!IsDialogMessageW+0x5f6
0022f938 61eced28 mfc100u!CWnd::IsDialogMessageW+0x32 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winocc.cpp @ 197]
0022f944 61e6c3ad mfc100u!CWnd::PreTranslateInput+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4659]
0022f99c 61d0cc9c mfc100u!CDialog::PreTranslateMessage+0xcf [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 82]
0022f9ac 61eccec5 mfc100u!CDialogEx::PreTranslateMessage+0x29 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxdialogex.cpp @ 275]
0022f9c0 61eb8a28 mfc100u!CWnd::WalkPreTranslateTree+0x23 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3258]
0022f9d8 61eb922d mfc100u!AfxInternalPreTranslateMessage+0x41 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 233]
0022f9e4 61eb8a78 mfc100u!CWinThread::PreTranslateMessage+0xd [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 777]
0022f9f0 61eb895d mfc100u!AfxPreTranslateMessage+0x19 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 255]
0022fa00 61ecedfd mfc100u!AfxInternalPumpMessage+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 178]
0022fa2c 61e6cae3 mfc100u!CWnd::RunModalLoop+0xc8 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4714]
0022fa78 00d41197 mfc100u!CDialog::DoModal+0x12d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 638]
0022fbfc 61ede3c3 UITest+0x1197
0022fc10 00d42425 mfc100u!AfxWinMain+0x49 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]
0022fca4 76143677 UITest+0x2425
0022fcb0 77b49d42 kernel32!BaseThreadInitThunk+0xe
0022fcf0 77b49d15 ntdll!__RtlUserThreadStart+0x70
0022fd08 00000000 ntdll!_RtlUserThreadStart+0x1b

1. adımda açtığınız dizine bakarsanız bir çok alt dizinle dolduğunu göreceksiniz.

H:\BLOG\symbols>dir
Volume in drive H is TOSHIBA
Volume Serial Number is 4504-0DA4

Directory of H:\BLOG\symbols

29.12.2010  16:50    <DIR>          .
29.12.2010  16:50    <DIR>          ..
29.12.2010  16:53    <DIR>          wntdll.pdb
29.12.2010  16:53                 0 pingme.txt
29.12.2010  16:53    <DIR>          wkernelbase.pdb
29.12.2010  16:54    <DIR>          wkernel32.pdb
29.12.2010  16:54    <DIR>          mfc100u.i386.pdb
29.12.2010  16:54    <DIR>          wuser32.pdb
29.12.2010  16:54    <DIR>          comctl32.pdb
               1 File(s)              0 bytes
               8 Dir(s)  11.803.426.816 bytes free


Yukarıdaki callstack'e baktığınızda debugger'ın, UITest.exe ve senaryolar.dll modüllerinin sembol dosyalarını bulamadığını görüyoruz. Aslında, işletim sistemi ile gelen ve Microsoft'tan satın alınmış ürünlerin sembol dosyaları indirilecektir. Sizin, debugger'a diğer modüllerin sembol dosyalarını nereden bulabileceğini belirtmeniz gerekir. Bunun için yine Windbg'de, "File" menüsünden "Symbol File Path" seçeneğini tıklayın. Varolan ifadenin sonuna noltalı virgül ekleyin ve sembol dosyalarının bulunduğu dizini girin. Örneğin, benim için bu :
H:\BLOG\DebugSenaryolari\Release dizini. Ve, sembol path ifadem de aşağıdaki gibi olacaktır : SRV*H:\BLOG\symbols*http://msdl.microsoft.com/download/symbols;H:\BLOG\DebugSenaryolari\Release 

"Reload" checkbox'ını işaretleyin ve "OK" butonuna basın. Bir kez daha k komutunu çalıştırın. Bu kez tüm modüllerin sembol dosyasına ulaşılmış olunmalı :

0:000> k
ChildEBP RetAddr 
0022f26c 75b30962 ntdll!ZwWaitForMultipleObjects+0x15
0022f308 7614162d KERNELBASE!WaitForMultipleObjectsEx+0x100
0022f350 76141921 kernel32!WaitForMultipleObjectsExImplementation+0xe0
0022f36c 65aa10e2 kernel32!WaitForMultipleObjects+0x18
0022f3b0 00d41b1d Senaryolar!DeadLockDurumuYarat+0x82 [d:\work\blog\debugsenaryolari\senaryolar\aski.cpp @ 40]
0022f3bc 61e42c6f UITest!CUITestDlg::OnBnClickedButtonDeadlock+0xd [d:\work\blog\debugsenaryolari\uitest\uitestdlg.cpp @ 168]
0022f3c8 61e42e51 mfc100u!_AfxDispatchCmdMsg+0x3b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 82]
0022f3e4 61e76d36 mfc100u!CCmdTarget::OnCmdMsg+0x124 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 381]
0022f408 61ecc444 mfc100u!CPropertySheet::OnCmdMsg+0x1d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgprop.cpp @ 814]
0022f458 61d0cceb mfc100u!CWnd::OnCommand+0x92 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2675]
0022f46c 61ecbc47 mfc100u!CDialogEx::OnCommand+0x2f [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxdialogex.cpp @ 290]
0022f538 61ecbbba mfc100u!CWnd::OnWndMsg+0x66 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2081]
0022f558 61eca019 mfc100u!CWnd::WindowProc+0x24 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2067]
0022f5d0 61eca2a5 mfc100u!AfxCallWndProc+0xb5 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 248]
0022f5f4 61dc0ddb mfc100u!AfxWndProc+0x37 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 410]
0022f634 774a6901 mfc100u!AfxWndProcBase+0x56 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp @ 420]
0022f6e0 774acd1a user32!UserCallWinProcCheckWow+0x120
0022f724 774acd81 user32!SendMessageWorker+0x581
0022f748 74354e95 user32!SendMessageW+0x7f
0022f768 74354ef7 comctl32!Button_NotifyParent+0x3d
0022f784 74354d89 comctl32!Button_ReleaseCapture+0x113
0022f7e4 774a6238 comctl32!Button_WndProc+0xa18
0022f810 774a68ea user32!InternalCallWinProc+0x23
0022f888 774a7d31 user32!UserCallWinProcCheckWow+0x109
0022f8e8 774a7dfa user32!DispatchMessageWorker+0x3bc
0022f8f8 774c2292 user32!DispatchMessageW+0xf
0022f924 61ee0ac0 user32!IsDialogMessageW+0x5f6
0022f938 61eced28 mfc100u!CWnd::IsDialogMessageW+0x32 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winocc.cpp @ 197]
0022f944 61e6c3ad mfc100u!CWnd::PreTranslateInput+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4659]
0022f99c 61d0cc9c mfc100u!CDialog::PreTranslateMessage+0xcf [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 82]
0022f9ac 61eccec5 mfc100u!CDialogEx::PreTranslateMessage+0x29 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxdialogex.cpp @ 275]
0022f9c0 61eb8a28 mfc100u!CWnd::WalkPreTranslateTree+0x23 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3258]
0022f9d8 61eb922d mfc100u!AfxInternalPreTranslateMessage+0x41 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 233]
0022f9e4 61eb8a78 mfc100u!CWinThread::PreTranslateMessage+0xd [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 777]
0022f9f0 61eb895d mfc100u!AfxPreTranslateMessage+0x19 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 255]
0022fa00 61ecedfd mfc100u!AfxInternalPumpMessage+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 178]
0022fa2c 61e6cae3 mfc100u!CWnd::RunModalLoop+0xc8 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4714]
0022fa78 00d41197 mfc100u!CDialog::DoModal+0x12d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 638]
0022fbfc 61ede3c3 UITest!CUITestApp::InitInstance+0xf7 [d:\work\blog\debugsenaryolari\uitest\uitest.cpp @ 72]
0022fc10 00d42425 mfc100u!AfxWinMain+0x49 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]
0022fca4 76143677 UITest!__tmainCRTStartup+0x158 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 547]
0022fcb0 77b49d42 kernel32!BaseThreadInitThunk+0xe
0022fcf0 77b49d15 ntdll!__RtlUserThreadStart+0x70
0022fd08 00000000 ntdll!_RtlUserThreadStart+0x1b

Yazıyı fazla uzatmadan tadında bırakalım. Gelecek yazılarımda sembol dosyaları ve sembol ayarları konusunu detaylandıracağım.
Bu arada debugging ile ilgili internette bir çok kaynak mevcut. Ancak, en temel ve yaralı kaynak "Debugging Tools for Windows"un help uygulamasıdır.

Hoşçakalın
-faik

 

]]> Ani Ölümler ve IFEO https://docs.microsoft.com/archive/blogs/hmm/ani-lmler-ve-ifeo Fri, 15 May 2015 03:02:47 GMT https://blogs.msdn.microsoft.com/hmm/2015/05/15/ani-lmler-ve-ifeo/ Merhaba,
Bugün uygulamaların ani ölümleri ile ilgileneceğiz. İngilizcesi, “Sudden death”. Uygulamanın çalışmaya başlar başlamaz kapanması anlamına geliyor. Bugüne kadar karşılaşmış olabilirsiniz. Uygulamaya çift tıklarsınız ancak uygulama açılmaz veya çok kısa bir süre görünür ve kapanır
veya SCM (Service Control Manager) içinden bir servisi başlatırsınız ancak “service terminated unexpectedly” gibi bir hata alıyorsunuz veya servisin hiç başlamadığını görüyorsunuz. Uygulama loglarına baktığınızda aşağıdaki gibi kayıtlarla karşılaşabilirsiniz :

 

Log Name:      Application
Source:        Application Error
Date:          13.05.2010 17:14:09
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      bilgisayar_adı
Description:
Faulting application name: AniÖlüm.exe, version: 1.0.0.1, time stamp: 0x4bebdf34
Faulting module name: AniÖlüm.exe, version: 1.0.0.1, time stamp: 0x4bebdf34
Exception code: 0xc0000005

 

Log Name:      Application
Source:        Windows Error Reporting
Date:          13.05.2010 17:14:13
Event ID:      1001
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      bilgisayar_adı
Description:
Fault bucket 1859722586, type 1
Event Name: APPCRASH
Response: Not available

 

“Ani ölüm” durumundaki sorun da tam olarak bu esasında. Uygulama çalışmaya başladıktan bir süre sonra hata alıp kapansaydı geçen yazıdaki adımları uygulayabilirdik. Ancak, “ani ölümlerde” debugger’ı uygulamaya bağlayacak kadar dahi zaman olmaz.

Çözüm : IFEO ( Image File Execution Options ),
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

İşletim Sistemi, bir uygulamayı çalıştırırken bu Kayıt Defteri Anahtarını (KDA = registry key) muhakkak okur ve çalıştıracağı uygulama ile aynı adlı bir subkey olup olmadığını kontrol eder. Varsa eğer bu key’e ait kayıt defteri değerlerini (registry values) sorgular ve ona göre aksiyon alır. Örneğin, debugger değeri içinde yer alan uygulama çalıştırılır.

Meraklısına Not :
İşletim Sistemi’nin bir programı çalıştırırken hangi KDA’ları okuduğunu gözlemleyebilirsiniz. ProcessMonitor (ProcMon) adlı araç sistemdeki faaliyetlerin bir kısmını takip eder (dosya, network, kayıt defteri erişimi, process/thread faaliyetleri). ProcMon’u aşağıdaki adresten indirip kurabilirsiniz :
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
#1 ProcMon’u çalıştırın
#2 Herhangi bir uygulamayı çalıştırın, örneğin notepad.exe
#3 Notepad.exe çalışmaya başladıktan sonra ProcMon’un trace almasını durdurun.
#4 Sonuçları açtığınız uygulamaya göre filtreleyin ( ProcessName is equal Notepad.exe )
#5 Filtrelenmiş sonuçta erişilen dosya ve kayıt defteri kaynaklarını görebelirsiniz.

 

Yazının sonunda test için kullanabileceğiniz küçük bir uygulama var : “AniÖlüm.exe”yi AniÖlüm.zip adlı sıkıştırılmış dosyanın içinde bulabilirsiniz. VC Çalışma Zamanı Kütüphaneleri ile ilgili bir sorunla karşılaşırsanız http://blogs.msdn.com/b/hmm/archive/2015/05/15/dump-alma-hang-mode-i.aspx 
adresindeki yazıma göz atabilirsiniz.

Deneme
#1 Uygulamayı bir dizine kopyalayın ve üzerine çift tıklayın.
#2 Explorer içindeyken imleç beklemeyi gösteren animasyonu başlatacak, sonra imleç normale dönecek. Bu arada uygulama açılmayacak.
#3 Görev Yöneticisini açın, processes sekmesine gelin, ve isme göre uygulamaları sıralatın.
#4 AniÖlüm.exe’yi tekrar çalıştırın, kısa bir süreliğine Görev Yöneticisinde AniÖlüm.exe’yi görebilirsiniz. Veya, yukarıda bahsettiğim ProcMon
aracıyla AniÖlüm.exe’ye ait işlemleri görebilirsiniz.

 

Image File Execution Options ve dump almayı hazırlanma

 

#1 “C:\Program Files\Debugging Tools for Windows (x86)” dizinine DumpAO.bat isimli bir dosya açın.

#2 Dosyanın içine aşağıdaki satırı kopyalayın :
cscript.exe "C:\Program Files\Debugging Tools for Windows (x86)\adplus.vbs" -crash -o c:\dumps -quiet -sc %1

#3 Registry Editor’ü açın (regedt32.exe)

#4 Aşağıdaki KDA’yı bulun :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

#5 Bu anahtarın altına adı “AniÖlüm.exe” olan yeni bir alt anahtar yaratın.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\AniÖlüm.exe

#6 AniÖlüm.exe adlı anahtarın altına yeni bir kayıt defteri değeri tanımlayın. Bu yeni değerin adı debugger, tipi string, içeriği de
"C:\Program Files\Debugging Tools for Windows (x86)\DumpAO.bat" olacak. Çift tırnaklar dahil.

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\AniÖlüm.exe
  Name:            debugger
  Type:            REG_SZ
  Data:            "C:\Program Files\Debugging Tools for Windows (x86)\DumpAO.bat"

 

Artık AniÖlüm.exe uygulamasını her çalıştırdığınızda cdb.exe de çalışacak ve AniÖlüm.exe her exception ürettiğinde c:\dumps dizini altına dump dosyası üretecek. Şimdi bunun denemesini yapalım. AniÖlüm.exe uygulamasını çalıştırın ve c:\dumps dizininin içine bakın. Aşağıdaki dosyaları görmeniz gerekir (sizde dosya isimleri farklı ama aynı formatta olacaktır).

 

C:\dumps>dir /s
Volume in drive C has no label.
Volume Serial Number is 2073-7A27

Directory of C:\dumps

13.05.2010  15:25    <DIR>          .
13.05.2010  15:25    <DIR>          ..
13.05.2010  15:25    <DIR>          Crash_Mode__Date_05-13-2010__Time_15-25-1212
               0 File(s)              0 bytes

Directory of C:\dumps\Crash_Mode__Date_05-13-2010__Time_15-25-1212

13.05.2010  15:25    <DIR>          .
13.05.2010  15:25    <DIR>          ..
13.05.2010  15:25             4.809 ADPlus_report.txt
13.05.2010  15:25    <DIR>          CDBScripts
13.05.2010  15:25           314.078 PID-0__Spawned0__1st_chance_AccessViolation__mini_1090_2010-05-13_15-25-17-462_1adc.dmp
13.05.2010  15:25        37.625.208 PID-0__Spawned0__1st_chance_Process_Shut_Down__full_1090_2010-05-13_15-25-24-053_1adc.dmp
13.05.2010  15:25        44.724.812 PID-0__Spawned0__2nd_chance_AccessViolation__full_1090_2010-05-13_15-25-18-041_1adc.dmp
13.05.2010  15:25            43.164 PID-0__Spawned0__Date_05-13-2010__Time_15-25-1212.log
13.05.2010  15:25            13.866 Process_List.txt
               6 File(s)     82.725.937 bytes

Directory of C:\dumps\Crash_Mode__Date_05-13-2010__Time_15-25-1212\CDBScripts

13.05.2010  15:25    <DIR>          .
13.05.2010  15:25    <DIR>          ..
13.05.2010  15:25            28.637 PID-0__Spawned0.cfg
               1 File(s)         28.637 bytes

     Total Files Listed:
               7 File(s)     82.754.574 bytes
    

 

 

Hoşçakalın

-faik

]]> Crash Mode, 1st/2nd chance exception, mini/full https://docs.microsoft.com/archive/blogs/hmm/crash-mode-1st2nd-chance-exception-minifull Fri, 15 May 2015 02:02:36 GMT https://blogs.msdn.microsoft.com/hmm/2015/05/15/crash-mode-1st2nd-chance-exception-minifull/ Merhaba,
Artık dump alma ile ilgili temel adımlara alıştığınızı umuyorum. Bu kez exception oluşturan uygulamaların dump’larının nasıl alınabileceğine değineceğim. "Dump Alma ( Hang Mode - I )" makalesindeki UITest.exe’yi kullanacağız. Uygulamayı çalıştıralım ve “AccessViolation” butonuna basalım. İşletim sistemi, versiyonuna bağlı olarak bir takım kurtarma girişimlerinde bulunabilir, size seçenekler sunabilir. Ama, sonuçta uygulama kapanacaktır :

 

 

1st/2nd Chance Exception

 

Olanları şöyle özetleyebiliriz :

 

#1 Exception throw edilir ve İşletim Sistemi uygulamaya exception’ı handle edip edemeyeceğini sorar. Bu durumu “1st chance exception” olarak da adlandırıyoruz. Eğer uygulamaya bir debugger bağlı ise o zaman debugger bir dump alabilir. Eğer debugger adplus ile çalıştırılmışsa cdb.exe, bir minidump (aşağıda anlatacağım) dosyası üretir. Exception durumlarında debugger’ların ne yapabileceklerini özelleştirebilirsiniz. Dolayısıyla, debugger istediğiniz başka bir eylemi de gerçekleştirebilir. Örneğin, aslında adplus, cdb.exe’nin sadece minidump oluşturmasını değil aynı zamanda log dosyasına da exception’la ilgili bilgiler yazmasını sağlar.

 

#2 Uygulama exception’ı handle edebiliyorsa kontrol uygulamada kalır ve uygulamaya çalışmaya devam eder.

 

#3 Eğer uygulama exception’ı handle edemezse o zaman işletim sistemi uygulamayı kapatmaya karar verir. Bu duruma da “2nd chance exception” denir. Aynı şekilde, eğer bir debugger uygulamaya bağlı ise debugger istenen eylemi gerçekleştirecektir. Örneğin, adplus ile çalıştırılmış cdb.exe bu durumda bir fulldump dosyası üretecektir. Sonra da uygulama kapanır. Aslında, bu aşamada bir dump daha yazılır. O da “1st chance process shutdown” exception’ından kaynaklanan dumptır.

 

Adım adım crash dump alma

#1 UITest.exe uygulamasını çalıştırın.

#2 Elevated ( Run as Administrator ) bir komut satırı açalım.

#3 “C:\Program Files\Debugging Tools for Windows (x86)” dizinine geçelim.

#4 Aşağıdaki komutu yazıp çalıştıralım :

Adplus -crash -pn UITest.exe -o c:\dumps -quiet

Komut çalışınca aşağıdaki gibi bir yazı görebilirsiniz. “quiet” modda çalıştırdığımız için sembol dizini uyarısı komut satırına yazılıyor. Sonra da debugger’ın uygulamaya başarıyla bağlandığı belirtiliyor.

 

C:\Program Files\Debugging Tools for Windows (x86)>Adplus -crash -pn UITest.exe

-o c:\dumps -quiet

WARNING!  An '_NT_SYMBOL_PATH' environment variable is not set.

Please check the application event log or the ADPlus-report.txt

for more details.

 

Attaching the debugger to: UITEST.EXE

                               (Process ID: 4376)

 

#5 Taskbar’da minimized olarak cdb.exe’nin çalışmaya başladığını göreceksiniz. Hatırlarsanız hang mod dump alırken bu uygulama kısa bir süre gözüküyordu sonra da kapanıyordu. Artık uygulama kapanana kadar cdb.exe de açık kalacak. Cdb.exe’yi maximize ederseniz aşağıdaki gibi yazıların olduğu bir komut satırı göreceksiniz :

 

mps\Crash_Mode__Date_05-12-2010__Time_15-26-0505; GN" isc

0:001> sxe -c @".echo ---;.echo --- 1st chance Stack_buffer_overflow exception -

---;.echo ---------------------------------------------------------------;.echo;

.echo Occurrence happened at: ;.time;.echo;.echo Faulting stack below ---;~#kvn2

50;.echo;.dump -u /mdi /c 1st_chance_Stack_buffer_overflow_exception_in_UITEST.E

XE_running_on_FHBEFES c:\dumps\Crash_Mode__Date_05-12-2010__Time_15-26-0505\PID-

4376__UITEST.EXE__1st_chance_Stack_buffer_overflow__mini.dmp; GN" -c2 @".echo --

-;.echo --- 2nd chance Stack_buffer_overflow exception ----;.echo --------------

-------------------------------------------------;.echo;.echo Occurrence happene

d at: ;.time;.echo;.echo Faulting stack below ---;~#kvn250;.echo;.dump -u /ma /c

 2nd_chance_Stack_buffer_overflow_exception_in_UITEST.EXE_running_on_FHBEFES c:\

dumps\Crash_Mode__Date_05-12-2010__Time_15-26-0505\PID-4376__UITEST.EXE__2nd_cha

nce_Stack_buffer_overflow__full.dmp;!elog_str ADPlus detected a 2nd chance Stack

_buffer_overflow exception in process UITEST.EXE and has taken the following act

ions at the time of the crash: Log Time Stack FullDump EventLog. The output dire

ctory is c:\dumps\Crash_Mode__Date_05-12-2010__Time_15-26-0505; GN" sbo

0:001> *

0:001> * ADPlus is monitoring: UITEST.EXE

0:001> * for  1st chance and 2nd chance exceptions as configured above.

0:001> * To change ADPlus configuration please refer to ADPlus.Doc. This file ca

n be found

0:001> * in the same folder as ADPlus.vbs

0:001> *

0:001> g

  

#6 Şimdi “AccessViolation” butonuna basın. Cdb.exe ve UITest.exe uygulamalarının kapanmasını bekleyin.

 

#7 c:\dumps dizinine bakın. İçinde adı “Crash_Mode__Date_05-12-2010__Time_15-26-0505” e benzer bir dizin oluştuğunu göreceksiniz. Bu dizinlerin debugger tarafından açıldığını biliyoruz. Hang mod dump alırken de benzer formatlı isimlerin olduğu dizinlerin yaratıldığını görmüştük. Şimdi bu dizinin içine bakalım. Aynı tipte log dosyalarının olduğunu göreceksiniz. Ancak hang moddan farklı olarak 3 tane “dmp” uzantılı dosya olduğunu göreceksiniz.

 

PID-4376__UITEST.EXE__1st_chance_AccessViolation__mini_1760_2010-05-12_15-31-56-867_1118.dmp

PID-4376__UITEST.EXE__2nd_chance_AccessViolation__full_1760_2010-05-12_15-31-57-101_1118.dmp

PID-4376__UITEST.EXE__1st_chance_Process_Shut_Down__full_1760_2010-05-12_15-32-06-054_1118.dmp

 

İsimlere dikkat ederseniz, “1st chance” “2nd chance” ve “full”/”mini” sözcüklerinin kullanıldığını göreceksiniz. 1st/2nd chance’ten sonra exception’nın tipi de yazılacaktır. Bizim örneğimiz “AccessViolation” exception’ı olduğu için “_AccessViolation_” sözcüğü eklenmiş.

Meraklısına not : Henüz dmp dosyalarını incelemeye başlamadık. Ancak, nelerle uğraşacağımızı merak ediyorsanız “PID-XXXX__UITEST.EXE__Date_MM-DD-YYYY__Time_HH-MM-SEC.log” dosyasını inceleyebilirsiniz.

 

 

Exception üreten ancak kapanmayan uygulamalar

Aslında neredeyse tüm uygulamalar bu sınıfa girer çünkü; büyük olasılıkla çalıştıkları s��re zarfında bir exception’la karşılaşabilirler. Exception handle edilebiliyorsa sorun yok. Uygulama çalışmaya devam eder. Duruma göre throw edilen bu exception’nın önemi olabilir ve biz de bu anda bir dump almak isteyebiliriz.

Bir deneme yapmak için yukarıdaki tüm adımları tekrarlayın. Sadece 6. adımda “AccessViolation Handled” butonuna basın. Sadece bir “1st chance access violation” minidump dosyası oluştuğunu göreceksiniz.

 

Minidump/FullDump dosyaları

Fulldump : Uygulamanın kullandığı tüm sanal bellek alanı, yüklenmiş tüm modülleri, handle tablosunu içerir.

Minidump : Bu kadar çok bilgiyi içermez, sadece threadlerin callstack’lerini ve yüklenmiş modüllerle ilgili bir takım bilgileri barındırır.

 

 

Hoşçakalın

-faik

]]> Dump Alma ( Hang Mode - II ) https://docs.microsoft.com/archive/blogs/hmm/dump-alma-hang-mode-ii Fri, 15 May 2015 01:46:14 GMT https://blogs.msdn.microsoft.com/hmm/2015/05/15/dump-alma-hang-mode-ii/ Merhaba,

Geçen sefer yanıt vermeyen ve işlemci zamanını az kullanan uygulamadan nasıl dump alınacağına değinmiştim. Bu kez yanıt vermeyen ancak işlemci zamanını çok kullanan bir uygulamadan nasıl dump alınabileceğini anlatacağım.

İlk yazımda belirttiğim gibi uygulama yanıt vermez durumu gelince yapmamız gereken ne kadar işlemci zamanı kullandığına göz atmak olmalı. Geçen yazıda yayınladığım UITest.exe uygulamasını açın ve “Yüksek İşlemci” butonuna basın.

Sonra, UITest.exe uygulamasını tutup çekmeye çalışın. Bir kez daha UITest.exe’nin başlığına “Not Responding” açıklamasının eklendiğini göreceğiz.

Görev Yöneticisini açın ve “Processes (işlemler)” sekmesinden “UITest.exe” uygulamasını bulun ve CPU kolonundaki değeri kontrol edin. Görmenizi beklediğim değer en az 100 / İşlemciSayısı dır.

Örneğin, bir işlemciniz varsa 100, ikiyse 50, gibi. İleride dump analizini tartıştığımızda nedenlerini daha ayrıntılı göreceğiz.

 

UITest.exe uygulamasını sonlandırmadığınız sürece bu seviyedeki işlemci kullanımı devam edecektir. Bu tip durumlarda uyguladığımız bir yöntem var : Birden fazla defa hang mode dump almak. Bu yöntemin arkasında yatan düşünce alınan dump dosyalarını karşılaştırıp hangi fonksiyonun bu soruna neden olduğunu görebilmek. Bu yöntemin başarısı, işlemci kullanımının yüksek olduğu süre ve alınan dump sayısı ile bağlantılıdır. Eğer işlemci kullanımı -UITest.exe örneğinde olduğu gibi- uygulama kapanana kadar yüksek devam ediyorsa bu durumda peşpeşe alınacak 4 dump yararlı olacaktır. Çünkü; genellikle sebep sonsuz döngüdür. Dumplarda callstack’lerin ortak fonksiyonlarını inceleyeceğiz. Öte yandan, yanıt vermeme durumu belli bir süre devam ediyorsa ve sonra uygulama normal çalışmasına devam ediyorsa bu yönetimin başarı şansı düşecektir. Çünkü; bu tip yüksek işlemci sıçramalarının sebebi çoğunlukla artan istek sayısıdır. Bu durumda alacağımız dumplar arasında ortak callstack’ler bulamayabiliriz bile.

 Şimdi adımları bir kez birlikte gözden geçirelim :

#1 Uygulamanın tepkisiz ve çok işlemci zamanı kullandığından emin olalım.

#2 Elevated ( Run as Administrator ) bir komut satırı açalım.

#3 “C:\Program Files\Debugging Tools for Windows (x86)” dizinine geçelim.

#4 Aşağıdaki komutu yazıp çalıştıralım :

adplus -hang -pn UITest.exe -o c:\dumps -quiet

Komut çalışınca aşağıdaki gibi bir yazı görebilirsiniz. “quiet” modda çalıştırdığımız için sembol dizini uyarısı komut satırına yazılıyor. Sonra da debugger’ın uygulamaya başarıyla bağlandığı belirtiliyor.

 

  

C:\Program Files\Debugging Tools for Windows (x86)>Adplus -hang -pn UITest.exe -o c:\dumps -quiet

WARNING!  An '_NT_SYMBOL_PATH' environment variable is not set.

Please check the application event log or the ADPlus-report.txt for more details.

 

Attaching the debugger to: UITEST.EXE

                               (Process ID: 7520)

 

#5 Komutu çalıştırdığınız anda taskbar’da kısa süreliğine “cdb.exe“ adlı bir programın açılıp kapandığını göreceksiniz. Cdb.exe kapandıktan sonra 4. Adımı tekrarlayın. Bu yöntemle 4 kez dump oluşturun.

#6 İşlem bittikten sonra c:\dump dizinine gidin. 4 yeni dizin oluşturulduğunu göreceksiniz. Hatırlarsanız her dizinin içeriğini geçen yazıda gözden geçirmiştik.

 

Gelecek yazımda crash mod dump almaktan bahsedeceğim.

 

Hoşçakalın

-faik

]]>