Read windump file

Perhaps the worst thing about getting a Blue Screen of Death is that it could be the result of any number of issues, from a faulty piece of hardware to a driver error to having a page fault in a non-paged area a result of a file not being found in memory.

In earlier versions of Windows, the BSOD showed you some error codes that were at least a little bit helpful. However, in Windows 10, the screen gives you a stop code you can write down and research and a QR code you can use with your phone. However, this only sends you to the Microsoft website and provides a description of certain error codes. What we find useful is configuring Windows to save a file that contains lots of information regarding the BSOD and how we can go about fixing the error.

This is called a minidump file. Navigate to the System Properties Control Panel menu. You can also change this location if you choose to.

However, if you do, keep in mind that most programs to troubleshoot the minidump logs are set to look for this location by default. A tool called BlueScreenView comes recommended for doing just this. You can download BlueScreenView by going to the official website and selecting either the bit or bit version of the application.

BlueScreenView will then look at the default minidump location and will look through the current logs that have been created. When you first use BlueScreenView, it will provide you with several pieces of information and at first, it may seem confusing. However, the format is straightforward and it does highlight the important information to get you started.

The files or applications that caused the crash will be highlighted in red, giving you a good idea of where to start correcting the issue. In this screenshot, we can see that on this specific minidump, there was an issue detected that affected three files; dxgmms2.

In this image, we can see that the watchdog. This is a good starting point as you can now check Google or Bing, to see how this could become a problem and possible solutions. We know that watchdog. As those were the affected files, we need to find out what those are as well. So those will also need to be looked into. Doing a quick check on Google, we can see that dxgmms2. Using this view of the Windows minidump file, we can deduce that the BSOD was likely caused by a graphics driver issue, which can typically be corrected by installing a newer version of the driver or reinstalling the current driver.

While driver issues are usually easily fixed, a BSOD that is a result of failed hardware is a different story. Here, you would still use an application such as BlueSceenWindow to find the cause of the error. There are several ways to do this; using a hardware memory checker or an application. Thankfully, Microsoft has included a memory diagnostics tool that has been included dating back to Windows 7.

If you choose the first option, be sure to save your work as Windows will close out. Once your computer restarts, the memory checker will load and start checking your memory. Depending on how much memory you have installed, the process can take a while. Data-seqno describes the portion of sequence space covered by the data in this packet see example below.

Ack is sequence number of the next data expected the other direction on this connection. Window is the number of bytes of receive buffer space available the other direction on this connection. Options are tcp options enclosed in angle brackets e.

Src, dst and flags are always present. The other fields depend on the contents of the packet's tcp protocol header and are output only if appropriate. Here is the opening portion of an rlogin from host rtsg to host csam. The S indicates that the SYN flag was set. The packet sequence number was and it contained no data. There was no piggy-backed ack, the available receive window was bytes and there was a max-segment-size option requesting an mss of bytes.

Csam replies with a similar packet except it includes a piggy-backed ack for rtsg's SYN. Rtsg then acks csam's SYN. The packet contained no data so there is no data sequence number. Note that the ack sequence number is a small integer 1.

On subsequent packets of the conversation, the difference between the current packet's sequence number and this initial sequence number is printed. The PUSH flag is set in the packet. On the 7th line, csam says it's received data sent by rtsg up to but not including byte Most of this data is apparently sitting in the socket buffer since csam's receive window has gotten 19 bytes smaller.

Csam also sends one byte of data to rtsg in this packet. On the 8th and 9th lines, csam sends two bytes of urgent, pushed data to rtsg. What we need is a correct filter expression for tcpdump. Recall the structure of a TCP header without options: 0 15 31 source port destination port sequence number acknowledgment number HL rsvd C E U A P R S F window size TCP checksum urgent pointer A TCP header usually holds 20 octets of data, unless options are present.

The first line of the graph contains octets 0 - 3, the second line shows octets 4 - 7 etc. Starting to count with 0, the relevant TCP control bits are contained in octet 0 7 15 23 31 HL rsvd C E U A P R S F window size 13th octet Let's have a closer look at octet no.

We have numbered the bits in this octet from 0 to 7, right to left, so the PSH bit is bit number 3, while the URG bit is number 5. Recall that we want to capture packets with only SYN set. In order to achieve our goal, we need to logically AND the binary value of octet 13 with some other value to preserve the SYN bit.

The packet contained 84 bytes of user data. Some UDP services are recognized from the source or destination port number and the higher level protocol information printed. If you are not familiar with the protocol, the following description will appear to be written in greek. The query operation was the normal one, Query , so the op field was omitted. The first answer record is type A address and its data is internet address In the second example, helios responds to query 2 with a response code of non-existent domain NXDomain with no answers, one name server and no authority records.

Since there were no answers, no type, class or data were printed. Note that name server requests and responses tend to be large and the default snaplen of 68 bytes may not capture enough of the packet to print. Use the -s flag to increase the snaplen if you need to seriously investigate name server traffic. By default a fairly minimal decode is done, with a much more detailed decode done if -v is used.

Be warned that with -v a single SMB packet may take up a page or more, so only use -v if you really want all the gory details. For information on SMB packet formats and what all te fields mean see www. If one is lucky, as in this case, the file handle can be interpreted as a major,minor device number pair, followed by the inode number and generation number.

Note that the data printed depends on the operation type. The format is intended to be self explanatory if read in conjunction with an NFS protocol spec. If the -v verbose flag is given, additional information is printed. For example: sushi. If the -v flag is given more than once, even more details are printed. Note that NFS requests are very large and much of the detail won't be printed unless snaplen is increased.

If a reply does not closely follow the corresponding request, it might not be parsable. The host pike responds with a RPC reply to the rename call which was successful, because it was a data packet and not an abort packet. The format is intended to be self-describing, but it will probably not be useful to people who are not familiar with the workings of AFS and RX.

If the -v verbose flag is given twice, acknowledgement packets and additional header information is printed, such as the the RX call ID, call number, sequence number, serial number, and the RX packet flags. If the -v flag is given twice, additional information is printed, such as the the RX call ID, serial number, and the RX packet flags. If the -v flag is given three times, the security index and service id are printed. Error codes are printed for abort packets, with the exception of Ubik beacon packets because abort packets are used to signify a yes vote for the Ubik protocol.

Note that AFS requests are very large and many of the arguments won't be printed unless snaplen is increased. Lines in this file have the form number name 1. The third line gives the name of a particular host a host is distinguished from a net by the 3rd octet in the number - a net number must have two octets and a host number must have three octets. The number and name should be separated by whitespace blanks or tabs. AppleTalk addresses are printed in the form net.

Other protocols just dump the protocol name or number if no name is registered for the protocol and packet size. NBP packets are formatted like the following examples: icsd-net. The nbp id for the lookup is The second line shows a reply for this request note that it has the same id from host jssmag.

The third line is another reply to the same request saying host techpit has laserwriter "techpit" registered on port ATP packet formatting is demonstrated by the following example: jssmag. Helios responds with 8 byte packets.

Helios resends them then jssmag. Finally, jssmag. The second indicates this is the last fragment. Id is the fragment id. Size is the fragment size in bytes excluding the IP header. Offset is this fragment's offset in bytes in the original datagram.

The fragment information is output for each fragment. The first fragment contains the higher level protocol header and the frag info is printed after the protocol info. Fragments after the first contain no higher level protocol header and the frag info is printed after the source and destination addresses. For example, here is part of an ftp from arizona. The small memory dump file contains the smallest amount of useful information that could help you identify why your computer crashed.

The memory dump file contains the following information:. To create a memory dump file, Windows requires a paging file on the boot volume that is at least 2 megabytes MB in size. On computers that are running Microsoft Windows , or a later version of Windows, a new memory dump file is created each time that a computer crash may occur. A history of these files is stored in a folder. If a second problem occurs and if Windows creates a second small memory dump file, Windows preserves the previous file.

Windows gives each file a distinct, date-encoded file name. For example, Mini The small memory dump file can be useful when hard disk space is limited. However, because of the limited information that is included, errors that were not directly caused by the thread that was running at the time of the problem may not be discovered by an analysis of this file.

Because there are several versions of Microsoft Windows, the following steps may be different on your computer.

If they are, see your product documentation to complete these steps. Click the Advanced tab, and then click Settings under Startup and Recovery. In the Write debugging information list, click Small memory dump 64k.

To change the folder location for the small memory dump files, type a new path in the Dump File box or in the Small dump directory box, depending on your version of Windows. Use the Dump Check Utility Dumpchk. The Dump Check Utility does not require access to debugging symbols. Symbol files hold a variety of data which are not actually needed when running the binaries, but which could be very useful in the debugging process. Or, you can use the Windows Debugger WinDbg.

WinDbg and KD. Select the Typical installation.