Article From:

One day, one application deployed on the server was hung up and there was no way to access the server.



【Under the view of event viewer, it was hard to find it.




The contents of the event viewer have no effect on our troubleshooting.

At this time, if there is a corresponding dump file, it will come in handy.

As long as you have dump files, you can find first-hand information about the moment the application hangs up. Some people may think it is very difficult to analyze dump files.

But recently there have been new dump analysis tools, such as vs2017, which can easily analyze dump files.

Next we will use several practical examples to see how to use vs2017 to analyze dump files.


dumpCollection of documents

Application hanging is a flash of things. After hanging up, there is no way to generate dump files. So first we need to set up automatic generation of dump files.

Open registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting




Create a new LocalDumps folder under Windows Error Reporting

Then add three items of DumpCount DumpFolder DumpType.




Demonstrate crash caused by stackoverflow error

We have created a simple console program.

class Program


        static void HogeHoge(string s)




        static void Main(string[] args)






After being compiled into exe, there will be no doubt that the following errors will occur.



Check that the dump file is actually generated.



Then we analyze the dump file and open it with VS2017, and it will have its summary information.



You’ll find that the exception message is written [the thread has run out of its stack] and it’s obvious that it’s stack overflow.

And on the right there are [debugging with hosting only] and [debugging with mixing] and [debugging with native only]

3 terms are involved here.

Managed =======> code that runs in a common language runtime is managed by the system, not by the programmer. Everyone knows that c about memory is managed by the CLR

Hybrid ======> invoke debuggers for managed and unmanaged code.

Native ======> suitable for unmanaged code.

If you do not call unmanaged code in your code, click on the first 2 buttons.


You will enter directly after clicking.



This error source level is very clear. Because we built the project PDB and source code. That’s why we can locate it directly. But crash actually happens on the server. Would that still be the case if you opened the dump file on the server?

Now let’s make a simulation.

Compile with Relase and delete the Program.cs file. Then re execute crash to generate dump file.

Then use the same step vs to open the click, debugging will prompt you not to find Program.cs.



In this way, we can get a lot less information on our obstacles. In this case, we can use several windows provided by vs to observe.

The following three.



The first window: thread window



The actual program often has many threads running, each thread switching and other important information can be observed in this window.


The second window: calling stack window.



The call stack window is linked to the thread window.


The third window is also the most important window: parallel stack.



As shown, each thread and its stack contents are very clear. But this example is relatively simple, even if you do not look at the first 2 windows, you can know why.

But if the actual application runs more than a hundred threads, visualizing these threads graphically is very useful for us to troubleshoot complex problems!


CPU100Crash analysis caused by deadlock

Because the system can configure crash to generate dump files automatically. But in some cases, such as deploying on IIS, web service CPU will not go to 100% until web stops service. At this time, we need to manually extract dump files.

Let’s simulate this scenario.

Create a new MVC program

public class HomeController : Controller
    async Task<string> GetAsync()
        var str = await new HttpClient().GetStringAsync("");
        return str;

    public ActionResult Index()
        var s = GetAsync().Result;
        return View();



The above code async/await will cause deadlock.

After we started the web application with IIS, the page circle has been changing to a blank page.

Open Windows task manager to find w3wp






Open the dump file with vs and click after debugging.

Open the parallel stack window.



You see, there will be many branches, which to start analysis, teach us a little skill, do not know how to start when the branch is longer!



Come in from HomeController.Index, stop at ManualResetEventSlim.Wait

Causes of Deadlock:





Speaking of dump, you may immediately think of WinDbg.

But the various commands of WinDbg are still difficult for novices, and the vs tools can help us analyze dump, and there are many problems that can be solved

Next, I will introduce an example of memory leak dump analysis.

Leave a Reply

Your email address will not be published. Required fields are marked *