WinDbg the wrong Little Mind

At the end of last year, the company has been on the line for nearly a year the system gradually appeared slow access, operation timeout problem. I use the WinDbg tool to grasp the memory image of the diagnosis, although not found any reason, but in the process also learned a lot of things, is now recorded as follows

I. "Failed to load data access DLL, 0x80004005" error

This error has another hint: "The version of SOS does not match the version of the CLR debugging".

In principle, unmanaged debugging tools, such as WinDbg, use the SOS.dll module, which, through the Mscordacwks.dll interface, invokes the Clr.dll implementation, ultimately implementing access to. NET runtime managed code. Here are two points to note

1. Sos.dll,mscordacwks.dll the versions must be consistent between the two

2. SOS.dll must be consistent with the invoked image runtime version

Any inconsistency between the two above will result in the above error message. For me, the server is the. NET 4.0 version, and I am the 4.6 version, which reports this error. There are two solutions to the solution

1. Use the correct version of each DLL. In general, in addition to replicating memory image files from the server, you also need to copy the above two DLLs, to ensure the success of debugging. At a minimum, copy sos.dll,windbg will automatically download the Mscordacwks.dll from the symbol file server to the current SOS.dll matching version during execution.

2. Use the Psscor4 tool. It is an advanced version of SOS.dll and adds several enhancements that automatically determine which memory image is currently being debugged and download the correct version of Mscordacwks.dll. It is recommended to use this scenario.

What does with "the version of SOS does not match the version of the CLR debugging" in WINDBG?

"Failed to the Load data access DLL, 0x80004005" –or–what is Mscordacwks.dll?

The version of SOS does not match the version of the CLR is debugging; SOS.dll version mismatch; Dump file different environment Mscordacwks.dll version issue

WinDbg Configuration Issues Summary

WinDbg SOS version mismatch problem resolution

Two. Memory leaks are the most common problem

The technical framework used by the company is relatively old, and most of them remain in the native SQL + DataTable approach. My first reaction was that the query returned too much data, and the DataTable object might be consuming too much memory. The following article specifically describes the positioning method.

Use Windbg+sos and WinDbg script to find the value of row N column in memory DataTable

Use WinDbg to troubleshoot a memory overflow problem

Too many exceptions are thrown, and incorrect cache usage can also cause a lot of wasted memory

Debug. NET Web Application High Memory-part 1

Debug. NET Web Application High Memory-part 2

Three. Thread deadlock is also a common problem

Use WinDbg to isolate deadlocks and resolve issues that are not responding to requests from software running in production environments

Debugging a Deadlock

Four. Finally, the mastery of each command is the basis for the utilization of WinDbg

"WINDBG Command Trilogy: (i) WINDBG command manual"

"WINDBG Command Trilogy: (ii) WINDBG SOS extension Command Manual"

"WINDBG Command trilogy: (iii) WINDBG sosex extension Command Manual"

WinDbg the wrong Little Mind