Crash debugging

A guide to crash debugging

Crash debugging can be a challenging task and requires a medium to high level of software knowledge. Debugging software crashes can be a time-consuming process, and it may require patience and persistence to identify and resolve the core issue.

If possible, ensure to first restore the livesite to a functional state either by implementing a workaround or by restoring the data. Replicate the crash in a controlled testing environment to debug without affecting the live site.

Preliminary investigation of crash:

Temporarily disable or isolate different components of the website This helps to narrow down the cause of the crash.
Reproduce the crash Try to reproduce the crash consistently. Understanding the steps or conditions that lead to the crash is crucial for debugging.
Check for error messages Look for any error messages, (server)logs, or crash reports. These can provide valuable clues about what went wrong.
Review recent change Determine if any recent updates or changes to the website, such as code deployments, configuration changes, or plugin installations, might have triggered the crash.
Check for memory leaks Memory leaks can cause crashes over time by consuming all available memory. Use memory analysis tools to check for memory leaks in the software.
Experiment with configurations Try different configurations or settings to see if the crash is related to specific configurations or environments.

Notice that Dynamicweb Care can help debugging and analyzing the root problem. Contact Care and make the data dump available for download.

Debugging Dynamicweb crash on IIS

Requirements:

Access to the web and SQL server.
An application with a .pdb (Stored debugging information) file attached.
Microsoft debugging tool DebugDiag2.3

Steps to attach symbols to application

Run Visual Studio as administrator
Open your project
Download DynamicWeb pdb file for the application from nuget (or contact Care to get the .pdb files)
Add this to your BIN folder
Make a debugging build
Copy the assembly (.dll) and symbols (.pdb) to the /bin folder of the web application

Identify the exception using DebugDiag

Open DebugDiag collector and select "Crash".
Select target type as IIS web application pool
Choose the specific application pool
Choose exception code

Exception Code 5. Select "full userdump" 6. Select a location for the application pool dump When the error occurs, it will dump the Application Pool with information. Please be patient, this may take some time.

Steps for using dotnet dump with Dynamicweb 10 container

Download Microsoft dotnet-dump
Move the dotnet-dump to 'dynamicweb/wwwroot/Files/debug
Open a terminal in the debug directory.
Collect a mini or a full dump by: - /dotnet-dump collect -p 1 or ./dotnet-dump collect -p 1 --type full

Steps to Debug a Crash Dump

Launch DebugDiag analyse and start a new analysis
Click on the "Analysis" tab
Select "Crash Hang Analysis" from the list of available analysis types
Click on the "Add Data Files" button
Browse and select the crash dump file you want to analyze
Click on the "Start Analysis" button to begin the analysis process.
Once the analysis is complete, DebugDiag will generate a report. Open the report to view information about the crash, including the call stack, threads, modules, and any potential issues.

Once the core problem to the crashes have been identified and the underlying error is clear, the next step is to prevent the problem of crashes from occurring again.