stop error 0x0000008E

[ramen92]

hey i just got a blue screen when i came back froms occer. this doesnt happen often but i thought i would upload the minidump. i have no idea of the cause of blue screen. i uploaded a minidump.

 

[Jase123]

blue screen aka blue screen of death

Did it look like this http://en.wikipedia.org/wiki/Image:Windows_XP_BSOD.png

Bluescreens can be caused by poorly written device drivers, faulty memory, a corrupt Registry, or incompatible DLLs. Bluescreens have been present in all Windows-based operating systems since Windows 3.1; OS/2 and MS-DOS suffered the Black Screen of Death, and early builds of Windows Vista displayed the Red Screen of Death after a boot loader error.

 

[ramen92]

i know what theyre caused by, ive troubleshot alot of my bsod's i just dont know how to read the minidumps to fix em myself.

 

[Jase123]

http://www.jsifaq.com/SF/Tips/Tip.aspx?id=4981

Check that out

Reading a Minidump with Visual Studio .NET

This section uses an example of a manually created minidump from Notepad in Windows 2000 and debugging in Windows XP.

Start Visual Studio .NET and, on the File menu, click Open Solution. Change the Files of type drop-down menu to Dump Files (*.dmp; *.mdmp), navigate to the minidump, and create a default project by clicking Open.

To launch the dump with the debugger, press F5. This will provide you with information to get started. The debugger creates a fake process; in the Output window, various module load messages are displayed. The debugger is recreated the crashed processes state only. After displaying a warning that the EXE contains no debug information, the debugger stops with the user's crash, such as an access violation. If you then examine the Call Stack window, you will notice the lack of symbols and a lack of useful information.
Figure 1. Initial Stack with No Symbols

To read a minidump, you typically need copies of the binaries involved. To find the right binaries, open the Modules window.
Figure 2. Initial Modules with No Binaries

Figure 2 shows the Notepad example and demonstrates two things. First, the paths to the binaries are marked with asterisks, which denotes the path on the user's workstation but the binary could not be found at that location on your machine. Second, the messages read “No matching binary found” in the Information field. The key to finding matching binaries is to look at the Version field and the file name. In this example, the version of most system files is 2195, which indicates Windows 2000. It does not immediately indicate the exact service pack (SP) or quality fix engineering (QFE), however. For more information, see the DLL Help database at http://support.microsoft.com/servicedesks/fileversion/dllinfo.asp.

At this point, you will need to find a Windows operating system CD or a user's workstation with the correct versions and copy the correct versions into a directory. It is not normally necessary to find every binary that was in the process, but it is important to find each binary that features on every relevant call stack. This will often involve both operating system binaries (such as Kernel32.dll) and your application binaries (in this example, Notepad.exe).

When you have found the bits and copied them to a local directory, on the Debug menu, click Stop Debugging. In Solution Explorer, right-click the project icon and click Properties on the shortcut menu. This will take you to the Debugging page. Fill in the Command Arguments to be MODPATH, followed by an equal sign, and followed by a semicolon-delimited list of places to look for binaries. In this example, it is:

MODPATH=m:\sysbits

After setting the path, press F5 to reload the minidump. MODPATH reuses the command argument to get the value to the debugger; a future version of Visual Studio .NET may have a better way of setting this, perhaps as an option in the Properties dialog box.

Although finding the binaries is unlikely to improve the call stack, it should resolve some issues in the Modules window, as shown in Figure 3.
Figure 3. Modules with Binaries

Instead of saying “No matching binary found”, it now says a combination of “Cannot find or open a required DBG file” or “No symbols loaded”. The first message occurs with system DLLs that use DBGs for their debugging information. The second message occurs for DLLs that use PDBs. Getting matching binaries will not necessarily improve your call stack; you also need debug information that matches them.
Method A: Symbols the Hard Way

To completely analyze a minidump, you should find debug information for everything, but to save time, you can find only the information you need. The example stack lists User32.dll and Kernel32.dll, so they need matching debug information.
Matching Debug Information

Operating system


Files required

Windows NT 4


DBGs

Windows 2000


DBGs, PDBs

Windows XP


PDBs

The best place to locate system symbols is at http://www.microsoft.com/ddk/debugging. You can also locate system symbols on the Support compact disc that ships with Windows NT Server and Windows 2000 Server operating systems. In this example, they were copied to the location of the binaries. In real instances, you will have non-Microsoft binaries listed, so you will need to have PDBs for them. Also in this example, the DBG and PDB for Notepad were also copied, because it was the sample application used.

After you click Stop Debugging on the Debug menu, pressing F5 will list a call stack, as shown in Figure 4. You may find that, as you add new binaries and debug information, your call stack will change. This is to be expected; a call stack can only be walked accurately with debug information, so as you add more information, your stack will get more accurate, which will often expose additional frames that were not in the original.

In this example, there was no crash. In real instances, you would have sufficient information to determine the cause of around 70 percent of your user crashes. In addition, this stack was created with the stripped symbols that Microsoft ships for system component, so there was no line number information. For your own binaries with full PDBs, you will get an even richer stack.
Figure 4. Call Stack with Symbols and Binaries

Symbol Servers

If you are dealing with many minidumps and performing general debugging, storing and accessing all the binary and PDB/DBG files can be difficult. Windows NT developed a technology known as a symbol server, which was originally conceived as storage for symbols but was extended to support finding binary files. The Windows NT debugger was the first tool to support this, but Visual Studio .NET also does so as an undocumented feature. For more information on symbol server, see http://www.microsoft.com/ddk/debugging/symbols.asp.

You can also retrieve symbols from the Microsoft symbol server. These symbols will be cached and indexed locally for you.
Method B: Symbols The Easy Way: Using Symbol Server

First, go to http://www.microsoft.com/ddk/debugging and download the debugging tools. You need Symsrv.dll, which needs to be on the path. You can either copy it next to devenv.exe or into your System32 directory, to allow Visual Studio .NET access to it. Once you have copied Symsrv.dll, you can safely uninstall the debugging tools. You will also need to make a local directory. For this example, create a local directory as C:\localstore.

In the Project Properties dialog box, set the Symbol Path on the Debugging page to:

SRV*c:/localstore*http://msdl.microsoft.com/download/symbols

This string tells the debugger to use the symbol server to get symbols and create a local symbol server, where they will be copied. Now, when you press F5 on the minidump, the symbols are copied from the Microsoft Web site, copied to the local store, and then used by the debugger. After the first time you do this, your performance will be quicker, because they will be retrieved from the local store rather than from the Web.

When debugging a non-Microsoft application, you should use a combination of methods A and B. Use A to get the system components and add paths to your bits and symbols by separating them with semicolons, such as:

c:\drop\build\myapp;SRV*c:\localstore*http://msdl.microsoft.com/download/symbols

Because the symbol server is an undocumented feature of Visual Studio .NET, there is no error reporting. If the syntax is incorrect or Symsrv.dll is not on the path, the symbols will fail to load with the error "No symbols loaded". You can also use symbol servers to store and retrieve binaries, but the MODPATH syntax needs to use symsrv*symsrv.dll* instead of SRV*.

Note The Microsoft symbol server does not contain binary files, but any symbol servers that you create can.

Symbol servers work for "live" debugging, as well, not only for minidumps. To do this, you will need to set the Symbol Path on the Debugging page properly.