Windows 7: BSOD: Errors 116 & 119: Interpreting the Minidump or Kernel Dump File

I had been having Blue Screen of Death (BSOD) crashes.  These were happening on one machine and not the other.  This was odd; both machines had virtually identical Windows 7 installations.  They also had the same motherboards and same amounts and kinds of RAM.  This post is a continuation in the effort to figure out why.

Given the similarities between the computers, I suspected the crashes were due to software.  Although the Windows installations were virtually identical, I was not always using exactly the same programs on both machines.  There was also a possibility that a CPU upgrade was responsible for a new bout of crashes:  both machines had previously had the same processors, but I had just installed a faster one on the crashing machine, and it had just begun crashing again.

In the previous episode, I had used BlueScreenView but had not known how to interpret its reports.  More accurately, I had not known how to interpret the minidump reports, viewable in BlueScreenView, that Windows would produce during a BSOD.  I wanted to be able to understand what the minidump file was telling me.

Understanding the minidump seemed especially important this time because, unlike the last time, the BSOD was not pausing onscreen long enough for me to see what it said.  It was flashing by so quickly that I just caught a glimpse of blue and then the machine was rebooting.  I recalled that I had seen, somewhere, a setting that would prevent that from happening.  Eventually I found it:  Start > Run > SystemPropertiesAdvanced.exe (or Control Panel > System > Advanced tab) > Startup and Recovery Settings > uncheck Automatically restart.  At present, my other settings there were for "Write an event to the system log," "Kernel memory dump" (not "None" or "Small memory dump (256KB)), "Dump file = %SystemRoot%\MEMORY.DMP," and "Overwrite any existing file" was selected.  I wasn't sure if those were the right settings; that's just what I had.  One source told me that I would want to overwrite because the MEMORY.DMP file would eat up lots of disk space.  With these settings, I would have a minidump for every crash and a MEMORY.DMP for only the most recent crash.  So then I clicked OK and got this message:

System Properties

Windows might not be able to record details that could help identify system errors because your current paging file is disabled or less than 800 megabytes.  Click OK to return to the Virtual Memory settings window, enable the paging file, and set the size to a value over 800 megabytes, or click Cancel to change your memory dump selection.

What we were inferring, from this, was that I could opt for the small memory dump with my existing settings, or else I would have to change the paging file settings.  Right there in the Advanced tab, I went to Performance Settings > Advanced tab > Virtual memory Change.  I had a 16MB paging file on drive C and a minimum 2GB paging file on another drive.  Apparently the kernel dump needed at least an 800MB paging file on drive C.  Since at least the days of Windows XP, I had emphasized putting the bulk of the paging file on another drive, in the belief that this would enhance performance.  A search now led to the suggestion that, especially on a machine with substantial RAM, I would rarely if ever run out of RAM and actually use the paging file.  On the other hand, a different post in that same thread quoted Microsoft as saying that paging files are used often and should be located on fast (and, obviously, uncompressed) drives if available.  A quick look at pagefile.sys on the second drive indicated that it was presently at the minimum 2GB size I had set for it, on a system with 12GB RAM.  So it seemed that advice to make the paging file half as large as RAM, or twice as large, or some other similar value, might significantly overstate how large a paging file I would actually need.  There had long been warnings that setting the minimum size too low would impose at least a slight performance hit, because Windows would have to dynamically resize the pagefile if it needed more space; but I thought that saving or otherwise manipulating a larger file might also cause a slowdown.  I concluded that the paging file probably was not being used often, that I didn't want to preallocate space that I might need for some other purpose in a pinch, that a fixed larger size could have its own drawbacks (including being inadvertently saved in a drive image), and therefore I should set the paging files on both drive C and the other drive to the System Managed Size > Set option.  After a reboot, I saw that the memory dump settings were as I had left them and the paging file size (with a full set of programs loaded) was 18427MB recommended and 24571MB currently allocated, or about 150% and 200%, respectively, of installed RAM.

One thing still on the burner was the indication, picked up from somewhere, that maybe I should be looking into the Windows Event Viewer (Start > Run > eventvwr.msc).  It seemed that Event Viewer was an alternative to BlueScreenView, so I wasn't sure I needed it.  Another recommended approach was to start by looking at the minidump to find the BCCode or STOP code, the cause, and the time when it happened.  I could see that BlueScreenView was showing me the Crash Time, the Bug Check Code, and a Caused by Driver column of information.  I didn't see a column for STOP codes.  I went into View > Choose Columns and saw that there wasn't even a column for STOP codes.  I had forgotten that Bug Check and STOP codes were synonyms.  Looking again, I saw that the three .dmp files shown in BlueScreenView all displayed Bug Check Codes of 0x00000116.  The "Caused by Driver" column listed three diffrent drivers, highlighted in the lower pane, but what was this bug check code telling me?  Microsoft's Bug Check Code Reference said that Bug Check 0x116 was VIDEO_TDR_ERROR.  The detailed description said, "This indicates that an attempt to reset the display driver and recover from a timeout failed."  (Later, I saw a suggestion that I would have found FaultWire more informative.  For this particular error code, I examined the suggestions below.)

So that was interesting.  It wasn't the CPU; it was the relatively new video card, an MSI R6570-MD2GD3 LP Radeon HD 6570 2GB.  I'd had it for a few weeks.  It seemed to me that the crashes were happening especially when I was running the Opera browser.  I couldn't make anything of the parameter information provided in the Bug Check Code Reference and listed in BlueScreenView, but I did do quick searches for the three drivers that were listed, for the three .dmp files shown in BlueScreenView:  pacer.sys, atikmpag.sys, and discache.sys.  Nothing jumped out at me for the other two, but I had seen pop-up dialogs referring to atikmpag when running Opera, and now it appeared that atikmpag.sys BSODs were related to video hardware problems (e.g., having a video card in the wrong slot). A right-click in Control Panel > Device Manager > Display Adapters indicated that I was already using the latest driver for the video card, and Opera said I was using the latest version.  Possibly this was happening only when Opera was overloaded:  I usually had a bunch of tabs open.  I decided to try the approach of killing Opera as soon as an atikmpag dialog popped up.  But the next crash wasn't due to Opera -- it wasn't running at the time -- so this was more like background information for the time being.  The next several runs of Opera produced no crashes, so possibly one or more of the steps taken here solved the problem.

Previously, I had gotten minidumps after an indication that my dump file size (presumably meaning my pagefile) was too small. Now that that was no longer a problem, I believed I could expect to see full kernel dumps instead of minidumps. I shelved my budding search for guidance on interpreting minidumps, to wait and see what I would get next.  After the next crash, I did have both a new minidump visible in BlueScreenView and a full MEMORY.DMP file in C:\Windows.  I wasn't sure how to view the MEMORY.DMP, so I ran a search and saw two options.  One was to upload the .DMP as an attachment to a request for help (at e.g., SevenForums.com).  I had a slow connection and my .DMP was about 1GB, so the recommended alternative (in an ExpertsExchange post) was to use Microsoft Debugging Tools for Windows.  (I had learned that I didn't have to pay to see the answers provided in ExpertsExchange.com threads; I just had to scroll to the bottom of the screen.)  The solution seemed to be to download the Windows SDK for Windows 7.  This gave me winsdk_web.exe.  That turned out to be a 2.5GB download that would require 4.5GB when installed.  I looked at my notes from the last time I flirted with the SDK.  I had apparently downloaded more than necessary; I was now seeing advice to download only the Debugging Tools for Windows.  (In my version of winsdk_web.exe, these were under Developer Tools, not under Common Utilities.)  This would be a 177MB download requiring 419MB when installed.  It downloaded and installed directly; it didn't give me an option of saving the download for future reinstallation.  It did not seem that it had actually downloaded 177MB, though; it was done in just a few minutes, and that would not have happened on my slow connection.

While that process was unfolding, I cleaned up the following notes that I had accumulated in the meantime; this post returns eventually (below) to the topic of using the SDK to read MEMORY.DMP.

One such miscellaneous note:  I saw a webpage on which Microsoft suggested two different sequences of steps, depending on whether Windows would start or not.  Since Windows was starting for me, their suggestion was, first, to undo recent changes using System Restore.  I had been having this problem for several days, past my most recent restore point.  Besides, by this point I believed I had traced the problem to the video hardware and/or Opera.  So the next step was to consult Control Panel > Action Center for clues.  Nothing there.  Next, make sure I was current on Control Panel > Windows Update.  I had already done that.

The next step recommended by Microsoft was to search for drivers on the manufacturer's website.  Well, I hadn't done that, not exactly.  I had relied on Device Manager, but now I went to the webpage of the video card manufacturer.  To do that, I started with GPU-Z (similiar to CPU-Z).  I discovered that I had to choose the Install rather than the Portable option:  the latter would make GPU-Z not only uninstalled but uninstallable on that machine.  Fortunately, I learned this on the machine that I was not trying to diagnose.  On the machine being examined, GPU-Z ran, and it gave me lots of information, but it didn't give me any more manufacturer information than I had gotten from Device Manager:  I was being lazy, but now I saw that I had an AMD Radeon HD 6570.  For that purpose, System Information for Windows (SIW) was a competent alternative.  To get the actual manufacturer information, it seemed I had no alternative but to consult my receipt, or the box that the video card came in.  Oddly, according to Device Manager, SIW, and GPU-Z, the driver I had installed was actually newer than the latest one on the manufacturer's webpage.  I decided to try the Roll Back Driver option in Device Manager.  That put it back to a driver dated about four months earlier.  I hadn't actually installed that older driver, to my knowledge; evidently Windows downloaded and installed the older driver automatically.  So I would have to see if that fixed the problem.  And in the long haul, that was one possible reason for the reduction in BSODs that I would experience in coming days.

In the meantime, the next step recommended by Microsoft was to use Safe Mode to troubleshoot problems.  They explained how to get into Safe Mode, but not what to do once I was there.  One possible intention was that I would load safe mode without startup programs that might be causing the problem.  A clean boot could be helpful at times, but did not seem highly relevant to the kind of crash I was having.  My crashes could occur after hours of operation.  Microsoft's final suggestion was to check for hard drive and memory errors.  I had recently run Windows Explorer > right-click on a drive > Properties > Tools > Check Now > check both options, and had also run MemTest86+.  These did not appear to be the problem in this case.

FaultWire offered other suggestions specifically oriented toward error 116.  The problem, they felt, was probably either in the driver or in hardware that was either defective or improperly installed.  On the video driver side, they suggested using their own commercial (nonfree) Driver Genius or Radar Sync to verify that I had the latest drivers, assuming I hadn't been comfortable with a direct search of the manufacturer's site.  On the hardware diagnostic side, they pointed me toward their Fix-It Utilities and System Suite, and also toward Eurosoft's PC Check and Iolo's System Mechanic (all commercial).  They also suggested checking the Windows 7 compatibility list. 

I did get another BSOD, within a day or two, but this time the error was different.  The number was 119 and the message was, "The video scheduler has encountered an unexpected fatal error."  I got it while running the Windows Experience Index test, so in that sense it seemed to be provoked by demanding use, as when Opera had been overloaded (above).  FaultWire had nothing new to add to what it had already said for error 116:  check the drivers, consider faulty hardware or incorrect hardware installation.  I hadn't previously searched the Win7 Compatibility Center, but now I did, and saw that there was no entry for my particular graphics card.  It was an MSI card, and a search of the Compatibility Center for "MSI" by itself turned up over 800 items, so it's not as though the database was weak.  I had evidently just stumbled into a product that was not listed.  I wasn't sure if that meant it hadn't been checked, or if it had been checked and was definitely not compatible.  Either way, this now seemed like something that I obviously should have checked before -- "obvious" being the standard word for what we have learned about, after we have learned it (or re-learned it, as the case may be).  I checked the manufacturer's page for the video card.  I was not impressed with MSI's website in this regard:  searching did not find the product, and when I did finally drill my way down to it, I got a notice:  "The specifications may differ from areas."  Some kind of typo there, but apparently they sold different products under the same model name.  I emailed MSI customer service, to verify that I was understanding the compatibility situation correctly.  They said no, it definitely was compatible.

I tried running the Windows Experience Index again, several weeks later.  By that point, I had rolled back the driver and had taken most if not all of the other steps described above.  This time, it did not crash.  I had also had no further crashes, with Opera or otherwise, during those weeks.  It seemed the driver rollback may have been the solution.  Having evidently solved the problem, the following notes are provided just for future reference.

By this point, I had installed SDK (above).  This gave me a couple of folders (e.g., C:\Program Files\Debugging Tools for Windows) and a Start Menu shortcut for a folder called Microsoft Windows SDK v7.0.  Choosing Open from the context menu for that folder shortcut took me to the C:\Program Data\Microsoft\Windows\Start Menu\Programs\Microsoft Windows SDK v7.0 folder.  There, I saw a shortcut for CMD Shell.  This opened up a command window.  It said, "The x64 compilers are not currently installed.  Please go to Add/Remove Programs to update your installation."  I went to Control Panel > Programs and Features > select Microsoft Windows SDK for Windows 7 (7.0) > click Change at the top of the list of programs there > Repair > Next.  But that didn't help.  I did a search and found that few people had had this problem.  My guess was that I got this message because I had installed only a fraction of the full contents of the SDK, and the solution was to install more of it, probably through that same Programs and Features route.  In that case, it seemed I might just ignore the message.

To use the SDK for reading MEMORY.DMP, Dirk Smith said I would actually run WinDbg.exe.  The link to this program (now located in C:\Program Files\Debugging Tools for Windows (x64)) had been installed in another Start Menu folder.  So evidently I was on the wrong track, when I opened the CMD Shell, or maybe WinDbg was just a front end for the command line.  Dirk said I needed to start by using WinDbg to find the proper symbol files.  This involved going into WinDbg > File > Symbol File Path.  There, I typed this:

srv*c:\cache*http://msdl.microsoft.com/download/symbols

Then I clicked OK.  Nothing seemed to happen.  But perhaps it was downloading the appropriate symbols quietly, which was what Dirk seemed to be saying.  The next step was apparently to go into WinDbg > File > Open Crash Dump > navigate to C:\Windows or wherever MEMORY.DMP was.  This got me a command window that seemed to hang, but apparently it was just figuring things out.  After a minute or two, it came back with errors:

Module load completed but symbols could not be loaded for atikmpag.sys.
Module load completed but symbols could not be loaded for atikmdag.sys.
Probably caused by:  dxgmms1.sys

Dirk said I could ignore the first two lines, but I wasn't so sure.  As noted above, an atikmpag file was named in one of my minidumps and I was seeing references to atikmpag in Opera.  He said I should focus on the last line, the reference to dxgmms1.sys.  That one hadn't been named in my minidumps.  Dirk told me to type "!analyze -v" (without quotes) in the command line at the bottom of the WinDbg screen.  That got me another error 119 message, and more besides:

****************************************
*                                                                             *
*                        Bugcheck Analysis                      *
*                                                                             *
*****************************************

VIDEO_SCHEDULER_INTERNAL_ERROR (119)
The video scheduler has detected that fatal violation has occurred. This resulted
in a condition that video scheduler can no longer progress. Any other values after
parameter 1 must be individually examined according to the subtype.

Arguments:
Arg1: 0000000000000001, The driver has reported an invalid fence ID.
Arg2: 0000000000004362
Arg3: 0000000000004363
Arg4: 0000000000004363

Debugging Details:
------------------
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0x119
PROCESS_NAME:  System
CURRENT_IRQL:  a
LAST_CONTROL_TRANSFER:  from fffff880015e322f to fffff8000307ed40
STACK_TEXT: 
[displaying, here, only the right end of each line - RW]
nt!KeBugCheckEx
watchdog!WdLogEvent5+0x11b
dxgmms1!VidSchiVerifyDriverReportedFenceId+0xad
dxgmms1!VidSchDdiNotifyInterruptWorker+0x19d
dxgmms1!VidSchDdiNotifyInterrupt+0x9e
dxgkrnl!DxgNotifyInterruptCB+0x83
atikmpag+0x52dc
atikmdag+0x4f526
atikmdag+0x4d479
atikmdag+0x62070
atikmdag+0xfb298
atikmdag+0x1015de
atikmdag+0x10161d
atikmdag+0x101714
atikmdag+0x101845
atikmdag+0x108d7b
atikmdag+0xfa0dc
atikmdag+0x4d15f
atikmpag+0x5ddb
nt!KiInterruptDispatch+0x16c
amdppm!C1Halt+0x2
nt!PoIdle+0x52a
nt!KiIdleLoop+0x2c

STACK_COMMAND:  kb
FOLLOWUP_IP:
dxgmms1!VidSchiVerifyDriverReportedFenceId+ad
fffff880`053b9eb9 c744244053eeffff mov     dword ptr [rsp+40h],0FFFFEE53h
SYMBOL_STACK_INDEX:  2
SYMBOL_NAME:  dxgmms1!VidSchiVerifyDriverReportedFenceId+ad
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: dxgmms1
IMAGE_NAME:  dxgmms1.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  4ce799c1
FAILURE_BUCKET_ID:  X64_0x119_dxgmms1!VidSchiVerifyDriverReportedFenceId+ad
BUCKET_ID:  X64_0x119_dxgmms1!VidSchiVerifyDriverReportedFenceId+ad
Followup: MachineOwner

Dirk said the right ends of the STACK TEXT lines were important for identifying third-party drivers.  Atikmpag and atikmdag were prominent there, just before (i.e., below) the dxgmms1 lines.  Anyway, the next step was to type "lmv" into the WinDbg command line.  This command provided details on all running programs or drivers (not sure) when Windows crashed.  As instructed, I searched this pile of information (using Ctrl-F) for the "probably caused by" item, which in my case (above) was dxgmms1.sys.  That search (with variations) found nothing.  I copied and pasted the WinDbg output into Notepad and tried my search there.  This time, it worked.  I tried it again in WinDbg, and this time it worked there too.  Not sure what I had done wrong the first time.  It seems the purpose of this step was to verify the manufacturer of the problematic file.  It looked like dxgmms1.sys came from Microsoft.  But if that Microsoft file had been the source of the problem, wouldn't I have been having these crashes before I installed the new video card?  WinDbg was showing me that the source of atikmdag.sys was AMD.  As Dirk said, Windows itself (i.e., Microsoft) was probably not the culprit.

It really looked like the purpose of this whole WinDbg and MEMORY.DMP rigmarole was just to get the identity of the driver manufacturer.  I wasn't sure this process was more effective than just doing web searches for the driver name and the error message.  I guess it added dxgmms1.sys to my list of possible causes, and provided confirmation that the atikmpag and atikmdag files were near the heart of this problem.  Whether I would be seeing more of this problem remained to be seen.  As noted above, the older driver presently seemed to have provided the desired stability.

There was one other approach that I hadn't pursued, and decided not to pursue at this point.  That was simply the suggestion to look at the time of the crash, in BlueScreenView, and then use NirSoft's MyEventViewer to examine events within a second or two before the crash.  Preliminarily, that seemed to be another way of getting at the contents of MEMORY.DMP, as listed in the STACK_TEXT above.  But possibly that would be more informative.  For me, further learning on that could await a future BSOD.

Windows 7: BSOD: PROCEXP111.SYS

My computer was sailing along, when suddenly I got a Blue Screen of Death (BSOD).  The message began, oddly, with a sentence fragment:

to your computer.

PROCEXP111.SYS

PAGE_FAULT_IN_NONPAGED_AREA

If this is the first time you've seen this Stop error screen, restart your computer.  If this screen appears again, follow these steps:

Check to make sure any new hardware or software is properly installed.  If this is a new installation, ask your hardware or software manufacturer for any Windows updates you might need.

If problems continue, disable or remove any newly installed hardware or software.  Disable BIOS memory options such as caching or shadowing.  If you need to use Safe Mode to remove or disable components, restart your computer, press F8 to select Advanced Startup Options, and then select Safe Mode.

Technical information:

*** STOP: 0x00000050 (0xFFFFFA8100043F20, 0x0000000000000000, 0xFFFFF880073B6DDD,0x0000000000000000)

*** PROCEXP111.SYS - Address FFFFF880073B6DDD base at FFFFF880073B5000, DateStamp 47194089

Collecting data for crash dump ...
Initializing disk for crash dump ...
Physical memory dump complete.
Contact your system admin or technical support group for further assistance.

I probably didn't need to type out all that information, but doing so provided a constructive outlet for frustration.  Besides, you never know what archaeologists of some future civilization will find absolutely crucial for understanding what they are digging out of the rocks.

This was the second time I'd gotten this BSOD, so evidently it was not going to be good enough to simply reboot and hope for the best.  To respond to the BSOD's first bit of advice, there wasn't any new hardware or software.  On the software side, I had recently restored a backup image of drive C that I had made more than a month earlier.  The first BSOD had occurred within the past few days, prior to the restoration.  In other words, I was suddenly getting BSODs on an install that had worked fairly well for weeks, with and also without software changes made during those weeks.

I did notice something atypical on the hardware side.  I had two different USB external drives connected.  That, itself, was not unusual, though it had not happened often.  The unusual part was that the system would not reboot without one of them being turned off.  It would get as far as giving me a message, which I think was "Loading Operating System," and then it would pause until I shut one of those USB drives off.

I wasn't actually doing anything in particular on the computer when the BSOD happened.  They had been up all night; I had just returned to the system in the morning; and at the moment I wasn't even using that computer; I was working on the other machine.  By the time I got to writing these notes, I didn't recall if I had even done anything on that computer.  Not much, anyway; nothing that would seem to have provoked the crash.

As I worked through this issue, I was guided by two posts I had written up a few months earlier, regarding a different STOP error.  One was a closer look at the "memory dump" concept mentioned toward the bottom of the BSOD; the other was a more general-purpose review of possibilities.  The memory dump investigation came to mind at this point because, on reboot, Windows 7 gave me a dialog that said, "Windows has recovered from an unexpected shutdown.  Windows can check online for a solution to the problem."  I hadn't always gotten this dialog after a crash.  It dimly seemed that something I had changed about my system, during the process of working through the prior memory dump post, had given me this information; otherwise I had to use something like BlueScreenView to see it.  The dialog gave me an option, "View problem details."  I took that option and got some technical information that I wasn't eager to read.  It pointed me toward two "Files that help describe the problem."  I copied the addresses of those files (without the actual filename), pasted them into the address bar in Windows Explorer, and looked at them.  One was an XML file that, if I just double-clicked on it (or if I pasted the full path and filename in Windows Explorer), would open as code in Internet Explorer.  This file was arguably more readable in Firefox, but I didn't see anything particularly informative in it.  The other was a minidump file that I opened in BlueScreenView.  (In Notepad, it was semi-gibberish.)  Problem is, I hadn't fared too well in interpreting the page dump, last time around, and that was still the case this time.  Following that previous guidance, I did notice that this day's minidump, and also the one from the previous BSOD, did contain lines referring specifically to PROCEXP111.SYS, named in the BSOD.  But, as before, I didn't know what else, if anything, I could do with the memory dump information.

Two other things worth noting about this crash.  First, after the crash, Glary Registry Repair found an unusually large number of registry errors.  Since I ran Glary every day, I suspected these were a result, not a cause, of the crash.  Second, in recent days the system had been functioning extremely slowly.  This seemed to depend on the number of programs running, but not entirely.  In particular, I was having the previously noted slowdowns that I had attributed to resource-hog programs (especially GoodSync and BeyondCompare).  Sometimes I noticed that, when those programs were out of the picture, the system sped up considerably; at other times, there seemed to be a lingering effect where the system continued to seem screwed up.  This was what had prompted me to do the system restore.  In that previous post, I mentioned trying Process Hacker to put a speed limit on these resource-intensive programs; but I also noted that this had not seemed to make much difference.  I wasn't sure that there was anything particularly wrong about the Windows 7 installation as a whole, and certainly wasn't eager to reinstall from scratch.

A search led to the information -- surprising to me, but obvious once stated -- that PROCEXP111.SYS was related to Sysinternals Process Explorer.  I had just begun using Process Explorer, after several weeks of using Process Hacker, to control certain programs -- especially GoodSync -- that made excessive resource demands, to the point of making the computer unusable while they were running.  I hadn't noticed specifically whether the previous BSOD named PROCEXP111.SYS as the culprit; but since it had occurred just one day earlier, probably PROCEXP111.SYS was named in that one too.  I probably could have figured this out from the minidump, with sufficient time investment.

I wasn't sure how to interpret this information.  Generally, Microsoft Sysinternals tools like Process Explorer had seemed relatively stable.  It seemed possible that the crash named PROCEXP111.SYS because, unlike Process Hacker, Process Explorer was actually succeeding in putting the brakes on some overly grabby programs, and they didn't like it.  That is, it may have been a problem with Process Explorer, but it may instead have been a problem with these other programs -- that, basically, they would either run at their preferred speed or not at all.

I tried another search.  This led to the suggestion that I should be using a more recent version.  I hadn't checked, but now I saw that mine was v. 11.04, copyright 2007.  Oops.  Upon closer examination, I saw that they were now up to v. 15.13.  I downloaded and installed the upgrade.  I wasn't sure how long it might be until the next BSOD due to Process Explorer, so I decided to close this post at this point.

Windows 7: BSOD: Memory Dump

As discussed in another post, I was trying to understand the words that appeared on a blue screen of death (BSOD) -- that is, a crash notice -- in Windows 7.  At the bottom of the screen, there was a mention of a "memory dump."  This post describes steps I took to learn more about that concept.

The general idea seemed to be that Windows had stored information about the current contents of the system's RAM to a file somewhere on my computer.  A search led to a Microsoft webpage that said I could find a list of such files in "the %SystemRoot%\Minidump folder."  Another search led to suggestions that %SystemRoot% was the same as %windir%, and that a person with a standard Start Menu could find %SystemRoot% by going to Start and typing "%systemroot%\system32."  I found that if I went to Start > Run and typed %systemroot% I would get a Windows Explorer session focused on C:\Windows.  This was consistent with my belief that the %SystemRoot% environment variable meant simply C:\Windows.

Unfortunately, I didn't see a C:\Windows\Minidump folder, and a search of my system also yielded no files of the format suggested in the Microsoft webpage (e.g., Mini022900-01.dmp).  It was possible that the webpage was not relevant to Win7 x64:  its list of the Windows versions to which it applied went up only as far as Windows 7 Beta.  But I wasn't finding a lot of great sources of information, so I stuck with it for the time being.

The Microsoft webpage posed the possibility that I lacked a Minidump folder because a memory dump would require "a paging file of at least 2 megabytes (MB) on the boot volume."  I had configured Win7 to use only a paging file on another drive.  So I went into Advanced System Settings.  (One way to get there was Control Panel > System > Advanced system settings.  Another way was Start > Run > SystemPropertiesAdvanced.exe.  I preferred the latter because, once I knew the name of the .exe file, I could put it into a batch file, if ever I wanted it to come up automatically, and also because the Run box would remember it, and that seemed faster:  the SystemPropertiesAdvanced.exe option would come up as soon as I hit S, so the whole thing could be done very quickly via WinKey-R-S, if I didn't have other items beginning with R in my Start Menu.)

In Advanced System Settings, I went into Advanced tab > Performance Settings > Advanced tab > Virtual Memory > Change.  There, I highlighted drive C, selected Custom Size, and specified a minimum and maximum of 10MB.  (I wanted most paging done on a drive other than the one containing the Windows program files, in the belief that dividing tasks between drives would improve performance.)  Then I clicked Set.  I got an error:  "The initial paging file size must be between 16 MB and 16777216 MB."  So OK, 16.  Now I got another error:  "If you disable the paging file or set the initial size to less than 400 megabytes and a system error occurs, Windows might not record details that could help identify the problem."  Once again, then:  400MB.

Then I hibernated the system and then restarted it, to see if now I would get a Minidump folder.  But I didn't get a BSOD.  I wondered why not.  The previous BSOD had come after leaving the system shut down all night.  Maybe I should have allowed a minute or two for the memory to clear itself out, before restarting the system.  I tried hibernating again, gave it a while, and then powered the machine up again.  Now I got a BSOD.  Same as before, but with the following change near the bottom:

Dump file size is too small - requires at least 521307888 bytes.
Future kernel memory dumps may require larger size.
Switching to minidump ...
Physical memory dump complete.

So it seemed that creating the paging file on drive C had indeed been necessary, but that (by my calculation) it needed to be at least 497MB for a full memory dump.  But did I now have at least a minidump file?  I punched the Reset button.  Oddly, I didn't get the choice (above) between continuing or deleting restoration data.  Instead, I got the menu that offers a Normal boot or Safe Mode.  I went with Normal, and Windows proceeded to load.

The Microsoft webpage said that I could change the location of the memory dump files by going to Advanced System Settings (above) > Advanced Tab > Startup and Recovery Settings.  There, I saw that my dump file was presently set to go to %SystemRoot%\MEMORY.DMP.  So it seemed I had been looking in the wrong place:  there was not going to be a C:\Windows\Minidump folder.  I went into C:\Windows and saw that there was also no MEMORY.DMP file.  A search of my system found no such file anywhere.  Apparently MEMORY.DMP was the file that I would have gotten if I'd had a paging file of at least 500MB.  So, OK, was there at least a file of the kind mentioned above, mini*.dmp?  No, but a search did turn up several *.dmp files with much longer names (e.g., 38f2213f-dd1e-452d-932eac0a3f6911e7.dmp).  But those were in a Firefox program folder.  They seemed to be Firefox crash data.  So far, I was not succeeding in creating a dump file that would shed light on my BSOD.  I went back into the paging file settings (above), changed the Custom Size to 1000MB, and prepared to hibernate and retry.  Later, though, I saw an indication that it might be necessary for drive C to have a pagefile large enough to hold "a file whose size equals your entire RAM plus one megabyte."  I had 8GB of RAM.  So I tried again with a 10,000MB pagefile on drive C.

Before contining with that discussion, I should catch up, here, with some other information that came up along the way.  For one thing, the Microsoft webpage said that I could use Start > Run > dumpchk.exe to verify that my system was correctly creating memory dump files.  But it wasn't clear whether that program, available through the Windows XP Support Tools, could still somehow be available in Windows 7.  It didn't work to just go to Start > Run > dumpchk.exe.  It looked like I could find tools that would read the dump file if I downloaded and installed Microsoft's Debugging Tools for Windows.  But that would require an MSDN subscription, which I didn't think I had, and it also seemed that I was getting into developer territory, over my head.  I took a look at the download webpage anyway.  It turned out that all I needed was my Hotmail login, and suddenly I was looking at options to download all kinds of Microsoft programs -- Windows, Office, Visio, etc.  But then I ran into a couple of problems when I searched in that page for "Debugging":  it didn't show Debugging Tools for Windows, and it said, "There is no subscription associated with your Live ID."  So I seemed to be at the end of the line there.

Another possibility was to download and install the Microsoft Windows SDK (Software Development Kit) for Windows 7.  It was advertised as providing tools, among other things, and that sounded good; sometimes a tool I didn't need at one point would be useful later.  I ran the downloaded file (winsdk_web.exe) and, in the Installation Options, I selected all of the Common Utilities and all of the Redistributable Packages, except for the Application Verifiers.  I deselected Windows Native Code Development and .NET Development.  This would be a 517MB download that, after installing, would apparently take about 250MB of drive space.  It was probably somewhat more than I needed, but I was not entirely sure how to trim it further.  During the installation process, however, I got an error:

Installation Failed

A problem occurred while installing selected Windows SDK components.

Setup could not find the file WinSDKRedist_amd64\WinSDKRedist_amd64.msi at any of the specified source locations http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup

A search for exactly that error message yielded no hits.  A related search led to an MSDN blog post that made me think the easiest way to proceed would be to download an ISO for the SDK and burn that to a blank DVD.  The ISO download webpage gave me several choices.  I selected the ISO for an AMD64 chip (GRMSDKX_EN_DVD.iso).  It would be a 1.4GB download.  I noticed that this would be a somewhat earlier version of the SDK; I hoped it did not matter for my purposes.

While that was downloading, I ran across a post that said an easier way to read memory dump (.dmp) files was just to use Nirsoft's BlueScreenView.  BlueScreenView was a portable with good ratings at Softpedia and CNET.  I let the SDK download proceed -- I figured I'd have time to play with its possibilities, once I had the ISO burned to a DVD -- but in the meantime I wanted to move ahead with BlueScreenView if I could.  Its homepage answered one question I'd wondered about:  it seemed to indicate that Windows 7, like XP, did create minidump files, so my lack of them wasn't due to the fact that I was running Win7.

When the SDK ISO finished downloading, I burned it to a DVD and ran its Setup.exe file.  That opened SDK options similar to those described above.  This was SDK for Win7 and NET Framework 3.5 SP1.  In this case, the installation options I selected were only the Debugging Tools for Windows and the Redistributable Components -- being uncertain, again, whether I would need all that.  I was kind of stuck, there, until I had a memory dump file to look at.

I hibernated the system, let it sit for several minutes, and rebooted.  No BSOD.  Windows came up normally.  Maybe I hadn't let it sit long enough.  I hibernated again, this time for an hour and a half.  But still no BSOD.  The stupid thing wouldn't fail!  It seemed that my testing of BlueScreenView would have to wait until the system reverted to a more cooperatively uncooperative stance.

Then I recalled seeing an indication that it was possible to generate a BSOD and/or a memory dump file manually.  I ran a search and found a YouTube video whose four-minute duration could be summarized as advising me to create and run this REG file, which I saved (as shown) with the name of CrashOnCtrlScroll.reg:

Windows Registry Editor Version 5.00

; *** CrashOnCtrlScroll.reg ***

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\i8042prt\Parameters]

"CrashOnCtrlScroll"=dword:00000001

; Undo:  "CrashOnCtrlScroll"=dword:00000000

and then reboot.  RightCtrl-ScrollLock x2 (i.e., hold the right-side Ctrl key and hit ScrollLock twice) would crash the computer and generate a BSOD.  As indicated by the last line of this batch file (which would function only as a comment, due to its leading semicolon), if CrashOnCtrlScroll value was set to 1, the crash would work.  If it was set to zero, it would not work.  So with a quick bit of editing in Notepad, this REG file could be used either to turn on the crash option or to turn it off.  I would just have to remember to reboot before relying on it.

So I ran the REG file -- and it worked.  I got a BSOD that was somewhat different from the one shown above.  After the first sentence, it added this remark:  "The end-user manually generated the crashdump."  A search confirmed that lots of people were aware of this tweak.  The other difference was that the STOP error code was E2 (i.e., 0x000000E2).

As before, the BSOD indicated that it had completed a dump of physical memory to disk.  Now I had both BlueScreenView and the SDK installed; surely I would be able to find the memory dump file.  A Hotgeek webpage informed me that BlueScreenView would search automatically for minidump files.  But on reboot, before I got to the point of starting BlueScreenView, Windows gave me a dialog that I had not seen before:

Windows has recovered from an unexpected shutdown

Windows can check online for a solution to the problem.

View problem details.

When I clicked to see the details, I got a nice presentation of information from this most recent, user-induced BSOD:

Problem signature:
Problem Event Name: BlueScreen
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional information about the problem:
BCCode: e2
BCP1: 0000000000000000
BCP2: 0000000000000000
BCP3: 0000000000000000
BCP4: 0000000000000000
OS Version: 6_1_7601
Service Pack: 1_0
Product: 256_1
Files that help describe the problem:
C:\Windows\Minidump\010912-21075-01.dmp
C:\Users\Ray\AppData\Local\Temp\WER-43040-0.sysdata.xml
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

According to that, it seemed that now, at last, I did have a minidump file.  I saw that, at last, C:\Windows\Minidump did exist, and it contained the file shown in that list of details. I tried viewing that file in Notepad, but it was a mess.  Definitely not the tool for viewing .dmp files.

The dialog offered a "Check for solution" button, so I clicked it.  It said it was checking, and then after a moment it disappeared.  I had hit a key on the keyboard, so maybe that was to blame.  Anyway, I started up BlueScreenView and, sure enough, it did show that file.  In its bottom pane, BlueScreenView seemed to be presenting that file's contents.

I also started up the Microsoft SDK programs that I had installed from the downloaded ISO that I had burned to DVD.  The specific program I started was called WinDbg.  In WinDbg, I went into File > Open Crash Dump.  It seemed to be looking for a file called MEMORY.DMP.  That was the name of the file that was supposed to have been created by SystemPropertiesAdvanced (see above) > Startup and Recovery Settings.  But for some reason, my BSOD had not generated the specified kernel memory dump file called %SystemRoot%\MEMORY.DMP.  There did not seem to be any such file on my computer.  I tinkered with those Startup and Recovery Settings and saw that I had the option to create a Small Memory Dump (256KB) in %SystemRoot%\Minidump.  I changed to that setting.  But this was puzzling.  Why had Windows created a minidump when SystemPropertiesAdvanced was requesting a full kernel dump?  Would this change of settings in SystemPropertiesAdvanced make any difference to anything?

If minidumps were only going to be 256KB, presumably the paging file on drive C wouldn't need to be any larger than 16MB (above).  While I was still in SystemPropertiesAdvanced, I went back into Advanced tab > Performance Settings > Advanced tab > Virtual memory Change and set the drive C paging file to a minimum and maximum of 16MB.  Before rebooting to make that new paging file setting take effect, I went back into WinDbg > File > Open Crash Dump, navigated to C:\Windows\Minidump, and tried to open the minidump .dmp file there.  It gave me a warning:

Kernel symbols are WRONG.  Please fix symbols to do analysis.

Your debugger is not using the correct symbols.

It went on from there.  But I felt this warning was not accurate.  What it should have said was, "You are a complete screwup!  You have no idea what you are doing!  Get the hell out of here!"  In other words, it presently appeared that the entire project of downloading and burning and trying to use the SDK was a complete farce, and I should just hang my head in shame and stop even pretending to utilize that software in an intelligent manner.  Which I did.  My tool of choice for minidump files, for the foreseeable future, would be BlueScreenView.

I wasn't sure whether a crash at this point would accomplish the same thing as a proper reboot, for purposes of resetting the paging file.  But I wanted to generate another minidump file, so I hit RightCtrl-ScrollLock x2.  This gave me a forced reboot but no BSOD.  Odd.  Maybe the paging file situation had interfered with it somehow.  Anyway, Windows restarted.  I had, again, the same dialog as above -- "Windows has recovered from an unexpected shutdown" -- and, as before, it checked for a solution and then vanished without further ado.  I took a look at C:\Windows\Minidump.  Now there were two minidump files.  (Incidentally, their sizes were 270KB and 283KB, so I wasn't sure exactly what SystemPropertiesAdvanced meant, when it referred to a 256KB minidump.)  I wanted to see what the second .dmp file said -- what would have been displayed at the bottom of the BSOD, regarding the paging file -- so I fired up BlueScreenView and took a peek.  It didn't contain any comments like those shown above (e.g., "Future kernel memory dumps may require larger size.  Switching to minidump ...").  But then I realized I didn't really care.  I had the minidump; perhaps I wouldn't need the full kernel dump (which I still didn't know how to produce).

What BlueScreenView did reveal, of possible interest, was a line referring to stdriver64.sys -- which was the driver mentioned in the original BSOD that had prompted me to commence this voyage of discovery.  I didn't know how to interpret that line, but I thought possibly its contents would be revealing in comparison against the next BSOD produced by a crash of stdriver.64, as distinct from these manually initiated minidumps.  So I would be keeping these two minidump files for future reference.

I was done with BlueScreenView for now, pending the next stdriver.64 crash.  I had managed to configure my system, and had learned something, so that now I was possibly prepared to read and begin to understand what was happening when stdriver.64 crashed.

Installed New Motherboard; Don't Want to Reinstall WinXP

I installed a new motherboard. I did not want to have to reinstall Windows XP, because that would mean reinstalling and reconfiguring all of the many pieces of software (including tweaks, Firefox extensions, etc.) that I had installed. I was looking for a shortcut. Unfortunately, WinXP would not boot with the new motherboard. At best, with much tinkering, I got it to go into Safe Mode; but even that died after a while: when I tried going into Safe Mode after that, I got an error message reading, "Windows XP Setup cannot run under Safemode. Setup will restart now." So then I found a very step-by-step webpage where there were instructions that seemed to offer a workaround. The instructions were kind of screwed up, though. They said there had been some problems with their HTML. Maybe they'll have it fixed by the time you read this. But at this writing, to make the instructions work, I had to do some translation. *** At this point, we undertake an optional detour. It has to do with the entry of DOS-style commands in Recovery Console. If you need that, great -- read this section. But this approach did not solve the problem. So if you're looking to continue with the main topic, skip to the *** END OF DOS DETOUR *** marker below. The first step was to boot from the WinXP CD, go into Recovery Console, enter the Administrator's password, and then enter some commands. The basic idea behind these commands was to make a backup of existing system files in a temporary folder, and then replace them with default, original WinXP system files. The files in question were as follows: copy c:\windows\system32\config\system copy c:\windows\system32\config\software copy c:\windows\system32\config\sam copy c:\windows\system32\config\security copy c:\windows\system32\config\default Those may look like folder names, but those were the actual system files in question. There were no extensions. I didn't feel like making a directory and making backups of these files, so I skipped this step. Most people would probably not want to do that, but I had just restored my whole C drive from a Drive Image backup, and I could use Image Explorer to go back into that image and extract these files if I needed them. If they were indeed corrupt, I wouldn't want to save them; and if they weren't, I didn't have another plan where I would need them anyway. Also, if I wanted another copy of them, I could copy them over on a CD if necessary. (The SOFTWARE file, at 8MB, was too big for a floppy.) The CD drive was accessible from within Recovery Console as drive E. I found it by typing D: and hitting Enter, followed by DIR to show me a directory listing of D. That turned out to be another partition on my hard drive, so I tried again with E. That directory listing looked like the CD, but I typed CD DOCS (since DOCS was one of the folders that showed up in the DIR for drive E) and watched my CD drive light up, which told me I was in the right place. Anyway, back at drive C, if I had wanted to make a backup of the files in question, I would have used the MD and CD combination. MD is short for Make Directory, and CD is short for Change Directory. You only have to make a directory once, and change to it once. Your DOS prompt will show you where you are after that. So here are the commands I would have entered to make the first backup copy:

md c:\windows\tmp
copy c:\windows\system32\config\system c:\windows\tmp\system.bak

You'd best be sure not to neglect that space before the last C:\. Anyway, those two commands would give you a copy of the SYSTEM file, which you would have copied as SYSTEM.BAK, in your newly created TMP folder. (I'm using capital letters for clarity. DOS is not case-specific. This isn't exactly DOS, but it's close enough for these purposes.) Since I didn't bother making those backups, I proceeded instead to the heart of the matter. The concept here is to copy fresh versions of some WinXP system files to your c:\windows\system32\config folder. Those files, listed above, come from your c:\windows\repair folder. If Recovery Console allowed for batch files, I could have done this all in one simple command (after copying these lines into Notepad to create the batch file). If I could have gotten into Safe Mode, I could have copied these files over all at once from my other computer. If I had thought of putting them on a USB flash drive, and had plugged it in before booting the WinXP CD, maybe that drive would have been recognized and I could have just copied them from there. Another possibility: Bart PE might recognize USB flash drives, so if I had wanted to go to the trouble of bailing out of Recovery Console and booting Bart PE, that might have been an option. Booting Linux was not an option, because at this point I didn't know of any live Linux CDs that would recognize and copy files to an NTFS drive, which is what my WinXP program partition was. Judging from the files shown in the REPAIR folder on my other computer, the idea was to copy each non-extension file (e.g., SAM, but not CONFIG.NT) from the REPAIR folder to the CONFIG folder. The instructions on the webpage mentioned earlier called for typing in the full pathname (e.g., copy c:\windows\system32\config\system c:\windows\tmp\system.bak) for each file, but I found it easier to CD to one of the folders (another word for "directory") and use a shorter command. So with all that background information, here's what I actually typed, choosing what seemed like the simplest route. I was starting at the C:\WINDOWS prompt because that's where Recovery Console started me. From there, I typed the following: CD SYSTEM32\CONFIG [This put me in the CONFIG folder.] COPY \WINDOWS\REPAIR\DEFAULT [This copied the DEFAULT file from the repair folder to my present location. For more information on COPY or any other Recovery Console command, request HELP by typing the command followed by /?. For example, COPY /? would give information on the COPY command.] COPY \WINDOWS\REPAIR\SYSTEM COPY \WINDOWS\REPAIR\SOFTWARE COPY \WINDOWS\REPAIR\SAM COPY \WINDOWS\REPAIR\SECURITY X So now I had all five replacement files from the REPAIR folder in the CONFIG folder. I didn't take the intermediate step of deleting the presumably corrupted versions of those files from the CONFIG folder before copying. I just used COPY, and answered Yes when it asked me, each time, if I wanted to overwrite the existing file in the CONFIG folder. Note that the Up arrow, in Recovery Console, would repeat the previous command. So it was easy to type those five commands; I just had to type the first one, and then I could repeat it by using the Up arrow, using Backspace to delete the filename, and then typing in the name of the next file. I verified that I had correctly copied each file by doing a DIR listing and checking the dates of the five files I had just copied. They were much earlier than most of the other files in the CONFIG folder. Then I typed EXIT and rebooted from the WinXP CD again. This time, according to the instructions on that guy's webpage, I was supposed to be able to boot right into WinXP, where I would have to take additional steps. I doubted it would work. But I tried. After typing EXIT, while the system was rebooting, I removed the WinXP CD from the CD drive and watched and waited. It didn't work. The system went to exactly the same point and then, once again, shortly after showing me the WinXP bootup logo, it flashed a BSOD (blue screen of death) and rebooted. *** END OF DOS DETOUR *** Next time around, I kept hitting F8 while it was going through the introductory stages of booting up. This gave me the menu of options, including Safe Mode. I selected "Disable automatic restart on system failure." That way, the sucker would freeze at the BSOD, giving me a chance to read it and see what it said. Sometimes BSODs would name a specific problematic driver. But that wasn't the case here. I just got the generic one:

A problem has been detected and Windows has been shut down to prevent damage to your computer. If this is the first time you've seen this Stop error screen, restart your computer. If this screen appears again ...

So I hit the computer's reset button and rebooted. This time, I used F8 to get into Safe Mode. I had just restored the system backup that I had saved in a drive image, so at this point I wasn't yet getting the "Windows XP setup cannot run under Safemode" error mentioned above. Instead, the system proceeded to recognize and "install" various pieces of hardware. In the previous go-round, I had decided to hit Cancel for each hardware wizard that came up. My idea was to let the system detect and install as much hardware as possible automatically. In the previous try, I had already followed the advice of disconnecting as much hardware as possible, just in case there was a conflict between the motherboard and some piece of equipment. I also ran Memtest86+ for a while; it found no errors. This time, I came across another webpage that made me think I should try a different approach. I didn't keep the link for this writing, but the advice was to begin with a Repair Install. The instructions were as follows:

Changing the motherboard (or the entire system) under your Windows XP installation will stop it working until the system files are repaired and updated. To do this, you should perform a Repair Install. The repair install process reinstalls all Windows system files while leaving directories, settings and user data intact. This should fix any corrupted files that are causing BSODs and crash issues. To perform a repair install: 1. Boot from the Windows XP installation CD 2. Choose the 'press enter to set up Windows XP now' option 3. Press F8 to skip through the EULA 4. Now press R to begin a repair installation Your system will go through the entire XP install process, but will not attempt to replace any of your existing data. It will simply reinstall the system files and redetect all hardware. Once the process has completed, your computer will reboot.

So I rebooted from the WinXP CD and did as I was told. As instructed, I pressed R to repair my designated Windows installation. In a previous go-round, I had learned the hard way that the other option would completely reinstall Windows. Some of my previously installed programs would still work, but many would not. That was a last-chance possible approach, but I was not too excited about it. The process ran; the system rebooted; and once again I got the same BSOD and reboot. So this time I tried something a little different. When the WinXP CD was loading, I noticed this message:

Press F2 to run Automated System Recover (ASR) ...

So this time I pressed F2. But that was no answer: it gave me a screen reading, "Please insert the disk labeled: Winodws Automated System Recovery Disk into the floppy drive." I didn't have a disk of that nature. So that was a dead-end. I tried booting back into Safe Mode. Now I got that error message again, "Windows XP Setup cannot run under Safemode." This time, I thought I might try using the command-line options in Recovery Console. I was a little discouraged because I had just come across a webpage where the guy said you could spend days trying to get a WinXP installation from one machine (or, in this case, from one motherboard) to work on another. In Recovery Console, I typed HELP to see the list of possible commands. From that list, based on previous experience and on comments I'd seen on various webpages in this day's research, I felt that the ones to investigate were BOOTCFG, CHKDSK, FIXBOOT, and FIXMBR. After further HELP inquiries for each of those (e.g., BOOTCFG /?), I decided to start with BOOTCFG /REBUILD. That was a mistake. I managed to create another boot entry, discovering at that point that there was no option to delete it. I hoped some such option would materialize once I was back in Windows, if I ever got there. Next, I ran CHKDSK /R. That, at least, was informative. It said, "The volume appears to contain one or more unrecoverable problems." I doubted that those problems had existed in the drive image that I had just restored, since I had restored drive images many times and had never seen this particular error message before. I figured the problems had probably originated when I had run the Repair Install. To complete this exploration of Recovery Console, I looked at HELP for FIXBOOT and FIXMBR. I went ahead and ran FIXMBR, typed Exit, and rebooted. It crashed at the usual place when attempting to install WinXP in Normal Mode. In Safe Mode, I got the usual "WinXP can't run under Safemode" message. I found a webpage where they said C:\WINDOWS\SYSTEM32\DRIVERS\IPVNMON.SYS might be responsible for that message. But I didn't have a file by that name on my system. Another webpage made me think that IPVNMON.SYS should be suspected only where the BSOD is naming that file specifically. At this point, it seemed that the "fresh install" option was the only alternative to a full reinstallation of Windows XP. To get there, I took the same first couple of steps as with the Repair Install, above:

1. Boot from the Windows XP installation CD 2. Choose the 'press enter to set up Windows XP now' option

But after that, this time I chose the other option: "To continue installing a fresh copy of Windows XP without repairing, press ESC." I pointed the installer toward drive C and told it to go ahead and install on top of the existing WinXP installation: "Leave the current file system intact (no changes)" and use the existing Windows folder. After maybe five minutes, the system rebooted and started me down that long road of Windows reinstallation. A half-hour later, having shot the better part of a day on the efforts described above, I was looking at a "new" Windows installation. The first question was, how bad was the damage to my previous drive C setup? I mean, the fresh installation had apparently dealt only with the C:\Windows folder, including the registry. I wanted an inventory of which programs were still operational and which would now have to be reinstalled. To conduct that inventory, I decided to look at the Start Menu found in C:\Documents and Settings\All Users\Start Menu\Programs. I figured that, if a program's icon was still good, that meant it was finding its target executable (usually an EXE file) somewhere; but if the icon had reverted to that plain white rectangle with the blue border, that meant the connection had been destroyed. The first thing I saw was that my original Start Menu was gone. I did have backup copy of my extensively customized Start Menu, however. I was pleasantly surprised. Most of the links still worked. The primary exceptions were the Microsoft, Google, Corel, and Adobe products, which it seemed I would have to reinstall, along with QuickTime, and about ten utilities. There would also be the issue that some programs were no longer installed to run on startup, but I felt those would be manageable. All in all, it looked like a decent outcome. After the hassle of reinstalling and configuring Windows and Microsoft Office programs and updates, along with the others just mentioned, it appeared that I would be up and running with my new motherboard. Of course, this whole process was premised on the assumption that, once I did the installations, I would have a stable system. The system seemed to be stable so far, in this first hour or so of fiddling around with it. I proceeded to install my wireless connection and activate Windows. Perhaps because of the reinstallation I had tried previously, I had to call Microsoft to activate. Then I began downloading and installing Windows updates. While that was underway, I began testing my other programs. It was a blow to discover that the Firefox extensions and configuration would all have to be reinstalled. As I looked further, the same appeared true for many other programs. The links on my backup copy of the Start Menu had found their targets, all right; but without the registry modifications that had been made during the initial installation, the linked programs would not actually run. There were no two ways about it: I gained little if anything from using this semi-fresh install, and I risked the downside of having many small and large problems, down the line, if this was anything like an upgrade installation -- which, as I had learned years earlier and had seen mentioned repeatedly on webpages since, was not the recommended way to go. I felt there was no choice but to abandon this attempt and return to a "real," full installation from scratch. But when I inserted the WinXP CD and started down the installation path, I was reminded that there was no "fresher" way of doing an installation. I could have wiped off the C drive and really started from scratch, but now I had second thoughts about doing all that. Maybe I really had nothing to lose from continuing in the present vein. So I decided to go ahead and try it out as it was. Maybe it would still save me an hour or two. Maybe there would be no feared complications. Well, about three hours later, I had my answer on that. I tried to install Symantec AntiVirus. It wouldn't install. Instead, it gave me an error message, "The System Administrator Has Set Policies to Prevent This Installation." I looked online for an explanation. Nobody seemed to have one. One person said s/he had solved the problem by manually deleting all registry references to Symantec Antivirus. I tried that. It didn't solve the problem. Microsoft had a tech support document on it, but they said it was just a workaround that might reduce my system's defenses against viruses. I used System Restore, in repeated tries, working my way back toward the start of my efforts to install and configure programs, and eventually I decided that the problem must be that there were still some lingering Symantec files or settings, somewhere on the drive; and if this could happen to their program, it could happen to others as well. So I finally did bite the bullet, wipe the disk and start a completely new WinXP installation -- which, of course, would have been half-done by this point, if I had just gone directly to that undesirable solution.