Debug SQLSERVER (2) use Windbg to debug SQLSERVER's Environment Settings

Debug SQLSERVER (2) use Windbg to debug SQLSERVER's Environment Settings debug SQLSERVER (1) generate a dump file debug SQLSERVER (3) Use Windbg to debug some SQL Server commands as you know in Windows, debugging can be divided into two fields: 1. kernel-mode debugging 2. User-mode debugging generally involves running programs.

Debug SQLSERVER (2) use Windbg to debug SQLSERVER's Environment Settings debug SQLSERVER (1) generate a dump file debug SQLSERVER (3) Use Windbg to debug some SQL Server commands as you know in Windows, debugging can be divided into two fields: 1. kernel-mode debugging 2. User-mode debugging generally involves running programs.

Debug SQLSERVER (2) use Windbg to debug SQLSERVER's Environment Settings

Debug SQLSERVER (1) to generate a dump file
Debug SQLSERVER (3) Use Windbg to debug some SQL Server commands

As you know, in Windows, debugging can be divided into two areas:

1. kernel state debugging

2. User-mode debugging

General programs run in user mode, including SQLSERVER, which depends on the Operating SystemWin32/Win64 APICall I/O or other services he needs

User-State program debugging is not the same as kernel-State program debugging, even if some commands are the same

Another important thing to note is live debug and dump file.

Live debug: directly attach the debugger to the process to make the process hang, so that the program being debugged cannot continue to execute the code

Dump file: it is usually a dump file. The dump file is all or part of the memory content generated by the process at that time and can be read by the debugger.

Full dump files generally have the. dmp extension, which generally does not contain paged out memory content.

The general extension of the mini dump file is. mdmp, which generally only contains the thread stack and the loaded Module name.

Windbg: it is a GUI debugger tool that can debug kernel and user State programs. Besides the Windbg debugger, there are also other debuggers, such as kd, cdb, and ntsd.

Simple Review

The application usesProcessRun: sqlservr.exe. in user-mode debugging, We will debug a separate process, whether it is using live debug (additional process method) or reading a dump file.

The memory space of the process can be viewed during debugging. In kernel-state debugging, we can see all processes and their memory space (note: we cannot access the dump file in the dump file when the dump file is generated

AlreadyPaged outThe part of the memory address)

Stack trace: the stack of code executed in a single thread. A thread can haveUser Mode StackAndKernel state StackIn User State debugging, we can only see the user State stack of each thread

A stack trace is a list of functions called by a thread.

Stack isLIFO Structure(Last in first out) is the term "push stack" and "pop stack ".

The stack is read from the bottom up, and the top call is the code currently being executed.

The following example

Child SP (Stack Pointer)

RetAddr (Return Address)

The stack trace can track the execution sequence of the system and return the call code. The debugger will construct the stack trace for us to better analyze.

Child-SP          RetAddr           Call Site 00000000`09cbe9e8 00000000`777b2f60 ntdll!NtSignalAndWaitForSingleObject+0xa 00000000`09cbe9f0 00000000`00bdc99e kernel32!SignalObjectAndWait+0x110 00000000`09cbeaa0 00000000`00bc4575 sqlservr+0x1c99e 00000000`09cbed40 00000000`00bc3ea8 sqlservr+0x4575 00000000`09cbed80 00000000`00bdcfad sqlservr+0x3ea8 00000000`09cbf370 00000000`01139d9c sqlservr+0x1cfad 00000000`09cbf430 00000000`032b34c7 sqlservr+0x579d9c 00000000`09cbf650 00000000`00bd2abb sqlservr!TlsGetValueForMsxmlSQL+0x4706d7 00000000`09cbf6c0 00000000`00bd0fda sqlservr+0x12abb 00000000`09cbf7e0 00000000`00bd2665 sqlservr+0x10fda 00000000`09cbf870 00000000`0117abb0 sqlservr+0x12665 00000000`09cbf8e0 00000000`0117c4b0 sqlservr+0x5babb0 00000000`09cbf9a0 00000000`0117a060 sqlservr+0x5bc4b0 00000000`09cbf9d0 00000000`0117a9ef sqlservr+0x5ba060 00000000`09cbfa60 00000000`734937d7 sqlservr+0x5ba9ef 00000000`09cbfaf0 00000000`73493894 MSVCR80!endthreadex+0x47 00000000`09cbfb20 00000000`7775f56d MSVCR80!endthreadex+0x104 00000000`09cbfb50 00000000`77893281 kernel32!BaseThreadInitThunk+0xd 00000000`09cbfb80 00000000`00000000 ntdll!RtlUserThreadStart+0x21

In the process of configuring the debugger, the final step is to match the symbol. When we open Windbg, we must set the path of our symbol file.

Symbolic Debugging Files: helps the debugger match the respective functions, classes, and variable names in the memory to the corresponding memory address and displacement.

If there is no Symbolic Debugging Files, we will see the following stack trace with only memory addresses

The extension of a symbolic file is usually pdb (if you writeC # codeYou will certainly see the debug symbol file under the bin directory during debugging. The debugger can parse this file format well.

Child-SP          RetAddr           Call Site 00000000`09cbe9e8 00000000`777b2f60 ntdll!NtSignalAndWaitForSingleObject+0xa 00000000`09cbe9f0 00000000`00bdc99e kernel32!SignalObjectAndWait+0x110 00000000`09cbeaa0 00000000`00bc4575 sqlservr+0x1c99e 00000000`09cbed40 00000000`00bc3ea8 sqlservr+0x4575 00000000`09cbed80 00000000`00bdcfad sqlservr+0x3ea8 00000000`09cbf370 00000000`01139d9c sqlservr+0x1cfad 00000000`09cbf430 00000000`032b34c7 sqlservr+0x579d9c 00000000`09cbf650 00000000`00bd2abb sqlservr!TlsGetValueForMsxmlSQL+0x4706d7 00000000`09cbf6c0 00000000`00bd0fda sqlservr+0x12abb 00000000`09cbf7e0 00000000`00bd2665 sqlservr+0x10fda 00000000`09cbf870 00000000`0117abb0 sqlservr+0x12665 00000000`09cbf8e0 00000000`0117c4b0 sqlservr+0x5babb0 00000000`09cbf9a0 00000000`0117a060 sqlservr+0x5bc4b0 00000000`09cbf9d0 00000000`0117a9ef sqlservr+0x5ba060 00000000`09cbfa60 00000000`734937d7 sqlservr+0x5ba9ef 00000000`09cbfaf0 00000000`73493894 MSVCR80!endthreadex+0x47 00000000`09cbfb20 00000000`7775f56d MSVCR80!endthreadex+0x104 00000000`09cbfb50 00000000`77893281 kernel32!BaseThreadInitThunk+0xd 00000000`09cbfb80 00000000`00000000 ntdll!RtlUserThreadStart+0x21

The following figure shows the displacement of sqlservr.exe and the code being executed in the address space, but we do not knowSpecific function nameIf symbols mapped is helpful, we can get more meaningful output.

Child-SP          RetAddr           Call Site 00000000`09cbe9e8 00000000`777b2f60 ntdll!NtSignalAndWaitForSingleObject+0xa 00000000`09cbe9f0 00000000`00bdc99e kernel32!SignalObjectAndWait+0x110 00000000`09cbeaa0 00000000`00bc4575 sqlservr!SOS_Scheduler::SwitchContext+0x84e 00000000`09cbed40 00000000`00bc3ea8 sqlservr!SOS_Scheduler::SuspendNonPreemptive+0xc5 00000000`09cbed80 00000000`00bdcfad sqlservr!EventInternal
 
   >::Wait+0x428 00000000`09cbf370 00000000`01139d9c sqlservr!ResQueueBase::Dequeue+0x19d 00000000`09cbf430 00000000`032b34c7 sqlservr!CheckpointLoop+0x1aa 00000000`09cbf650 00000000`00bd2abb sqlservr!ckptproc+0x47 00000000`09cbf6c0 00000000`00bd0fda sqlservr!SOS_Task::Param::Execute+0x11b00000000`09cbf7e0 00000000`00bd2665 sqlservr!SOS_Scheduler::RunTask+0xca 00000000`09cbf870 00000000`0117abb0 sqlservr!SOS_Scheduler::ProcessTasks+0x95 00000000`09cbf8e0 00000000`0117c4b0 sqlservr!SchedulerManager::WorkerEntryPoint+0x110 00000000`09cbf9a0 00000000`0117a060 sqlservr!SystemThread::RunWorker+0x60 00000000`09cbf9d0 00000000`0117a9ef sqlservr!SystemThreadDispatcher::ProcessWorker+0x12c 00000000`09cbfa60 00000000`734937d7 sqlservr!SchedulerManager::ThreadEntryPoint+0x12f 00000000`09cbfaf0 00000000`73493894 MSVCR80!endthreadex+0x47 00000000`09cbfb20 00000000`7775f56d MSVCR80!endthreadex+0x104 00000000`09cbfb50 00000000`77893281 kernel32!BaseThreadInitThunk+0xd 00000000`09cbfb80 00000000`00000000 ntdll!RtlUserThreadStart+0x21
 

From the output function name, we can see the Checkpoint thread

The preceding figure shows that worker thread waits for the CHECKPOINT command in the CHECKPOINT_QUEUE queue.

After adding the symbol file, you can see that the debugger converts the position of the stack trace. For example, add the module name to the module name and the function name to the function name.

 
  !
  
   or
   
    !
    
     ::
     
    
   
  
 

Set symbol path

The purpose of setting the symbol path is to enable the debugger to locate the position of the symbol file and load it during debugging.

Brief Introduction to symbolic paths and public/private Signed files

Private symbol file: contains all the symbol information required for debugging sessions (only open to Microsoft, private property of Microsoft)
Public symbol file: only selectively contains some symbol information (open to everyone)

The symbolic information is affiliated to a specified module and onlyThe debugger must use a module to load and analyze its symbolic information..

To use symbols in the debugger, we must first tell the debugger where these symbol files are located,That is, set the symbol path.. The symbolic path can beLocal folder path, CanAccess UNC pathOrSymbol server path.

Symbol server: during debugging, thousands of symbol files are involved, and the same symbol file contains different versions of symbol files on different platforms.

It is unrealistic to manually set the symbol path.Symbol server Concept.

The symbol server has a set of naming rules that allow debugging software to correctly find the desired symbol file. Generally, symbol servers are large and shared and placed on remote hosts.

In order to reduce the cost of network accessSymbol cache Concept, That isSave the symbolic file downloaded from the server to the local cache. When the debugger needs the symbolic file, it will first find it from the cache, and then download it to the server if it cannot be found..

　　1. Set the symbol path

The syntax for setting the symbolic path is as follows:

. Sympath [+] [path]

To overwrite the original path settings, use the new path:

. Sympath
 <新路径>

To add a new path based on the original path, you can use:

. Sympath +
 <新增路径>

If no parameter is included, the output is the currently set symbol path:

0: 000>. sympathSymbol search path is:
 
  
// The symbolic path has not been set.
 

For example, when debugging, I know that the desired symbol file is in the folder below"D: \ MyPdb ".

0: 000>. sympath D: \ MyPdb // overwrite the original symbolic path Symbol search path is: D: \ MyPdbExpanded Symbol search path is: d: \ mypdb

　　At this time, the debugger will record the new symbolic path above, but will not load any symbols from this path. to instruct the debugger to load the symbols, you can use the meta command reload.

This command can enumerate all loaded modules in the process address space and try to find the symbol files related to each module.

0:000> .reloadReloading current modules.....

If the debugger cannot find the file in the specified directory, an error message is returned:

*** ERROR:Symbol file could not be found. Defaulted to export symbols for xxx.dll

When the local cache path is not set, the debugger usesSymFolder.

　　Note that after you use. sympath to change or add a new symbolic path, the symbolic file is not updated automatically. You should execute the. reload command to update the file.

　　

　　2. symbol server and symbol Cache

The basic syntax for setting the symbol server is:

SRV * [Symbol cache] * server address

The syntax includes SRV boot, and the symbol cache and server address are each preceded by an asterisk boot.

In addition, we should always add Microsoft's public symbol library to our symbol path:

. Sympath + srv *
 <缓存地址>
  
* Http://msdl.microsoft.com/download/symbols
 

This is a public server of Microsoft. It is accessed through an http address, and not everyone can keep this URL in mind. The best way is to use it. the symfix command automatically remembers the above Microsoft symbolic server address. The syntax is as follows:

. Symfix [+] [Symbol cache address]

The following command is equivalent to the above. sympath command, instead of entering a long http address.

0:010> .symfix c:\windows\symbols0:010> .sympathSymbol search path is: srv*Expanded Symbol search path is: SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols

After the above settings, when symbols are required, Windbg will be automatically downloaded to the server, and then saved in C: \ windows \ symbols

Of course, we can also set it on the computer:

My computer = advanced system settings = Advanced Tab, click environment variables to create a new user variable, as shown in figure

Variable name: _ NT_SYMBOL_PATH
Variable value: SRV * D: \ PDB * http://msdl.microsoft.com/download/symbols/

Or

After installing the symbol file, specify a fixed path

Variable name: _ NT_SYMBOL_PATH
Variable value: C: \ windows \ symbols

2. Reload

If you are confused about the symbol file you are using, for example, the source code obviously does not match the line number, you 'd better re-load the symbol file. The command syntax is as follows:

. Reload/f/v [Module name]
. The reload command is used to delete specified or all loaded symbol files. By default, the debugger does not immediately re-search and load new symbol files based on the symbol path, it is postponed until the next time the debugger uses this file.

Use the/f parameter to immediately search for and reload the new symbol file.

Other parameters are described as follows:

/V: displays the detailed information in the search process.
/I: do not check the version information of the pdb file;
/L: only display module information. in kernel mode, the command is similar to the lm n t command, but the display content is more than the latter because it contains the user module information;
/N: only the kernel symbol is reloaded, and the user symbol is not reloaded;
/O: forcibly overwrite the symbol files in the symbol library, even if the version is the same;
/D: the default option when Windbg is used in user layer mode. It reloads all modules in the debugger module list;
/S: the default option when Windbg is used in kernel mode. It reloads all modules in the system module list. In addition, if the debugger runs in user mode, it loads the kernel module, you must also use the/s option. Otherwise, the debugger will only search the list of Debugger modules and cannot find the kernel module;
/U: detach a specified module. If you find that the current symbolic version is incorrect, use the/u Switch to uninstall it and then reload it.

The following command reloads the sqlservr Module

.reload /f  sqlservr.exe

I 've talked a lot about what symbol server and what symbol cache, But we generally only use local symbol files. In fact, the general way to set the symbol path is

1. Download the public symbol file, install it, and set

Address: http://msdn.microsoft.com/zh-cn/windows/hardware/gg463028

Double-click the downloaded installation package and install

Remember the following path !!

After installation, you can see the installed pdb in the E: \ Symbols \ path.

Pdb File

2. Set the symbols folder location in Windbg.

We can load an mdmp file at will.

After opening the dump file, enter the following commands in the Windbg command box in sequence:

.sympath  E:\Symbols

Reload

.reload

Enter. sympath and you will see that the current symbolic path is E: \ Symbols.

Of course, we cannot specify a symbolic path every time we debug the dump file. We can add the symbolic path to the environment variable.

In this way, the next time you open Windbg, you do not need to specify the symbol path more than once.

Open Windbg again, and we can find that Windbg first searches for the symbolic path from the environment variable. We can see that Windbg has been successfully searched.

This saves us the trouble of setting the symbol path every time.

Summary

In this way, the debugging environment is ready. The next article will introduce some Windbg commands.

References:

Http://blogs.msdn.com/ B /askjay/archive/2009/12/29/basic-debugging-concepts-and-setup.aspx

For more information about the symbolic path, symbol server, and symbol file, see Windbg symbol and source code article 2.

Welcome to Brick o (∩ _ ∩) o