SharePoint Study Notes-debug & troubleshooting-introduce windbg for diagnosis and debugging

windbg is a free source code-level debugging tool developed by Microsoft. It can be used for kernel mode debugging, user mode debugging, and dump file debugging. In the production machine of SharePoint, due to the lack of Visual Studio support, we can only obtain relevant information (such as ULS log and Database Log Files) through some peripheral means ), we can also use the dump file and windbg to intervene in the diagnosis and debugging of the production machine. This article mainly summarizes how to introduce windbg to SharePoint without specific applications.
1. Download windbg
you can download windbg from here to your local development machine. Please select the correct download link (for example: if you are an x86 machine, you can only download and install x86 tools. If your machine is an Intel 64-bit processor, you can only download and install x64 tools, if you select redistributable version, all three types of X86, x64, and itanium will be downloaded ). After the download is complete, install the tool on your local development machine (instead of the customer's machine.
during installation, some people set the installation directory to D: \ debug for convenience of using Extension: psscor2 later, you can also set this directory here.
after the installation is complete, you can see "debugging tools for Windows (x64)" in the Start Menu ---> Program ) "or" debugging tools for Windows (x32.

2. Installation Extension: psscor2
next, install extensions for managed code. By default, windbg is used to debug unmanaged code, if you want to debug the managed code, you need to install additional extensions. Here we choose psscor2 (originally SOS. DLL, psscor4 is now available, but for different.. NET Framework version. NET application also provides the net SDK command line debugger mdbg.exe). This extension can be used to diagnose managed threads, managed object heap, CLR stack, and so on. You can download psscor2 and decompress it. To facilitate expansion, we recommend that you copy the corresponding psscor2.dll to the d: \ debugdirectory (also in the directory where windbg.exe exists ).

3. Set symbolpath
The symbol file is a symbolic file. If you want to debug it more effectively, you need the symbol file. With it, windbg can compile your programCodeTranslate into commands that you can understand.
Symbol files can be in the old-fashioned coff format or PDB format. PDB is a program database file and contains a public symbol. In these debuggers, you can use a series of addresses to find the symbols of the loaded binary files. The operating system symbol files are generally stored in the % SystemDir % symbols directory. The symbolic file (. dbg or. PDB) of the driver is generally stored in the same directory as the driver file (. SYS file. Private symbol files contain information such as functions, local variables, and global variables, andSource codeThe associated row number information. For the customer, half of the symbolic files are public-these files only include public members.
Microsoft provides a series of symbols for your debugger, from which you can download the symbol file. We recommend that you download the symbol file to the Directory D: \ debug \ symbols for your convenience.
After the download is complete, you need to set the symbol file path in windbg, for example:

Enter in the input text (reference to the symbol file added here on the Network)

SRV * D: \ debug \ symbols * http://msdl.microsoft.com/download/symbols

 

You can also use the. sympath command. The command used is:

. Sympath + SRV * D: \ debug \ symbols * http://msdl.microsoft.com/download/symbols

When the debugger loads a binary file (DLL or EXE), it checks their related information, such as the file name, timestamp, and check value. If you have symbolic information, you can view the function name and their parameters on the call stack. If both the binary file and the PDB file come from your own application, you can see additional information such as private functions, local variables, and types.
We can put symbols, extensions, and dump files under the same Directory D: \ debug for our convenience.

4. Get dump
Now go to our production machine and find the process that our SharePoint runs. In this way, take the SharePoint Study Notes-how to locate the w3wp process where the website set is located,
On the production machine, Open Windows Task Manager (or run taskmgr.exe to open the task window), find the corresponding process, and create the dump, for example:

After the creation is successful, the system will tell you the location of the dump file. Copy it from the storage location on the problematic machine to a directory on your local machine for backup.

5. Start Using windbg
Now we have dump file for debugging. Under the File menu of the windbg program, select "file/Open crash dump" to open our dump file, then you can see information similar to the following:

Microsoft (r) Windows debugger version 6.11.0001.404 amd64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading dump file [D: \ debug \ w3wp. dmp]
User mini dump file with full memory: only application data is available
Symbol search path is: SRV * D: \ debug \ symbols * http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 version 7600 MP (4 procs) Free x64
Product: Server, Suite: terminalserver singleuserts
Machine Name:
Debug session time: Sat Nov 12 22:18:52. 0002011 (GMT + 11)
System uptime: 1 days 19:01:34. 239
Process uptime: 0 days 19:34:52. 000
Loading unloaded module list
Ntdll! Zwwaitforsingleobject + 0xa:
00000000 '77c1f6fa C3 RET

In the above information, you can find the storage path of your dump file and your symbol search path. At the bottom of windbg is the command window, which is also our main operation interface.

5.1 list modules
Run LM to check what modules are loaded by our w3wp process. The operations are as follows:

 

SharePoint developers can debug and diagnose modules such as feature receivers and Event Handlers by Loading modules to determine whether they are triggered, if you do not see their related assemblies loaded into the memory, most of them are caused by configuration settings, which greatly reduces the scope of diagnosis.

5.2 load psscor2
Remember the extension: psscor2 we downloaded earlier. It is used to debug the managed code. If we want to debug the managed code in w3wp, We need to load this extension first, in the windbg command line, enter

. Load D: \ debug \ psscor2 \ amd64 \ psscor2.dll

Because my production machine is 64-bit intel and the dump created by it is 64bit, I loaded psscor2.dll of amd64 version here. If you are debugging an x86-based process, you need to load psscor2.dll of the x86 version. To verify that psscor2.dll is successfully loaded, you can enter the following command
! Help
The input result is as follows:

* Mscordacwks. dll is frequently encountered here.

That is, extension cmd cannot be used because the mscordacwks. dll file of the source dump file is inconsistent with the version on the debug machine. This is because our problem machine is not the same as the debugging machine, so after we capture the dump file of the Managed Application on the problematic machine, the dump is analyzed on another machine. If the problem machine and the target machine's mscordacwks. if the dll version is inconsistent, the correct mscordacwks cannot be found on the target machine after the above windbg load command is used to load psscor2.dll. cannot Use debugger extension command.
For example, enter an extension command :! Threads
The error message received is similar:

**************************************** *****************************
* Symbols can not be loaded because symbol path is not initialized .*
**
* The symbol path can be set :*
* Using the _ nt_symbol_path environment variable .*
* Using the-y < Symbol_path > Argument when starting the debugger .*
* Using. sympath and. sympath + *
**************************************** *****************************
PDB symbol for mscorwks. dll not loaded
Failed to load data access DLL, 0x80004005
Verify that 1) You have a recent build of the debugger (6.2.14 or newer)
2) The file mscordacwks. dll that matches your version of mscorwks. dll is
In the version directory
3) or, if you are debugging a dump file, verify that file
Mscordacwks _ < Arch > _ < Arch > _ < Version > . Dll is on your symbol path.
4) You are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
Machine.

You can also run the debugger command. cordll to control the debugger's
Load of mscordacwks. dll .. cordll-ve-u-l will do a verbose reload.
If that succeeds, the SOS command shoshould work on retry.

If you are debugging A minidump, you need to make sure that your executable
PATH is pointing to mscorwks. dll as well.

Take a look at it with. cordll. The feedback is as follows:

Clr dll status: Error: Unable to load DLL mscordacwks_amd64_x86_2.0.50727.4963.dll, win64 error 0n2

This indicates that the mscordacwks_amd64_x86_2.0.50727.4963.dll file is not found for the captured dump file.

Mscordacwks. dll acts as the data access component (DAC) OF psscor2.dll to explain the data structure of the. NET program in the memory. Mscordacwks. dll is updated every time you patch the. NET Framework.

Solution: Simply copy the mscordackws. dll file on the client where the problem occurs, rename it as the desired file name, and place it under the appropriate search path. Obtain mscordacwks. dll from the client environment where the problem occurs. Its location is

32bit. net2.0/3.0	% Windir % \ Microsoft. NET \ framework \ v2.0.50727
32bit. Net 4.0	% Windir % \ Microsoft. NET \ framework \ v4.0.30319
64bit. NET 2.0/3.0	% Windir % \ Microsoft. NET \Framework64\ V2.0.50727
64bit. Net 4.0	% Windir % \ Microsoft. NET \Framework64\ V4.0.30319

Windbg requires that mscordacwks. dll be placed in the storage path of symbol or the installation of windbg, rather than in the same path as the dump file. Here is the D: \ debug we mentioned earlier. Use. cordll-ve-u-l to check whether a mscordacwks is successfully loaded.

Enter the command. cordll-ve-u-l in windbg and you will see

0:013>. Cordll-ve-u-l
Clr dll status: no load attempts

 

* Another important issue is how to handle 32-bit processes in a 64-bit environment.

Our sharepoint2010 website is running in a 64-bit server environment.

For iis7, the Enable 32-bit applications attribute of SharePoint application pool determines whether the process is a 32-bit process or a 64-bit process. For example:

 
For IIS6, to execute a 32-bit process, you need to execute cscript.exe adsutil. vbs set w3svc/apppools/enable32bitapponwin64 "true". Note that all application pools in IIS6 either execute 32-bit processes or do not execute them.
When importing dump on a client-side problem machine, use ctrl-shift-ESC to call out task manager. You can see whether the exported process is a 32-bit process or a 64-bit process.

If you use the create dump file function of task manager to generate dump on a 64-bit client, the 64-bit dump is obtained. For 32-bit processes, all memory addresses are 64-bit, and psscor and other tools cannot work. To identify the 64-bit dump of a 32-bit process, run the KP command. The method shown in wow64cpu in the call stack indicates that this is the 64-bit dump of the 32-bit process.

How to correctly generate dump for 32-bit processes running in 64 Environment?

Method 1: Run 32-bit Task Manager C: \ WINDOWS \ syswow64 \ taskmgr.exe to generate dump

Method 2: Install 32-bit debug diag or 32-bit adplus (32-bit debugging tools for Windows) in a 64-bit environment ). 64-bit debug diag 1.2 (beta version currently) can generate 32-bit dump.

To debug the 32-bit dump of a 32-bit process, you must use a 32-bit windbg. The debugging environment can be 32-bit or 64-bit. The SOS and Other plug-ins must be 32-bit.

For dump of 64-bit processes in 64-bit environments, use the 64-bit windbg in 64-bit environments. net debug, the 64-bit SOS, psscor2, sosex and Other plug-ins must be used

5.3 Other Common commands
After the mscordacwks. dll version is solved, we can use windbg & psscor2 to further analyze our program.
! Help Command (previously used)
The most commonly used command is! HELP command. You can use this command to list all available extended commands! Help [commandname] can be used to view detailed instructions for each specific extension name.

! Aspxpages command
This command displays the accessed ASPX page, thread ID, thread run time, and other information about each page. This information helps you understand which pages are too slow to access, and the verb action of the access.

! Threads command
Jump to the thread context you specified to view its stack information. implementation is similar to in Visual Studio. When we set a breakpoint for debugging, we can view the call stack information, this information shows the method chain contained when the program is executed until the breakpoint ).

! Clrstack command
Use! Clrstack can be used to view the current call stack! Clrstack-l can be used to view the current call stack and its local variables and values! Clrstack-P can be used to view the parameter variables and values on the current call stack! Clrstack-A can view all the local variables, parameter variables, and values on the current stack (in the format of stackaddress = stackvalue ).! The clrstack command only displays the call stack of the hosted code. You can use it to view the complete call stack! Dumpstack command

~ * E! Clrstack command
This command displays the CLR stack information of all threads. The displayed result may be long.
Of course, the use of windbg is by no means the commands mentioned here. It is often used to solve underlying problems. To master windbg, you must have a deeper understanding of the underlying things, here we only focus on how to introduce it in SharePoint debugging.