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.

Installing Windows XP SP3 in VMware Workstation 7.1 on Ubuntu 10.04

I had decided to stay with VMware Workstation 7.1 for a while longer, adopting a wait-and-see strategy toward VirtualBox and whatever other virtualization developments might be underway.  A couple of years had passed since I had first installed Windows XP on VMware Workstation in Ubuntu.  My old virtual machines (VMs) were creaking and malfunctioning.  It was time to create a new WinXP VM.

I had obtained mixed results from efforts to use VMware Converter to build VMs from existing WinXP installations or other sources.  I decided to build a fresh installation, installing XP within a newly created VM.  I had already installed VMware Workstation.  Now I started it as root user by typing "sudo vmware," and then I went into Ubuntu's Applications > Accessories > Terminal.  In Workstation, I went into Edit > Preferences and adjusted the settings that would apply to all VMs, some of which could only be set by root.  In the Preferences > Workspace tab, I went with the default settings for the most part.  For the default location of my VMs, I chose a partition on a separate hard drive for better performance.  In the Display tab, I selected the three Autofit options.  I selected all of the Updates options.  In the Memory tab, I left about 1.5GB of RAM for the system; the rest was for VMs.

When I was done with the settings, I killed that session and restarted VMware as a normal user.  I created a new VM with these characteristics:

• I started with a 40GB independent, persistent SCSI VM, but ran into some problems when I tried to shrink it, and ultimately had to start over.  Since it was easier to grow a VM than to shrink it, I decided on 20GB to start.  Although I initially created this as a preallocated space, it seemed that clones (which I made from time to time as backup, as the installation and tweaking process went along) would default to being non-preallocated, and I decided that was actually better until things got settled, because non-preallocated drives were smaller and therefore easier to clone and to back up.
• A 4GB independent, persistent IDE virtual drive, within this VM, for the paging file (VM > Settings > Hardware > Add).  This, I discovered, was best created after WinXP was installed.  Otherwise, WinXP was quite capable of brainlessly installing itself into this little partition and leaving the 20GB partition unused, thereby providing yet another reason to start over from the beginning.  Also, this drive was best created when the VM was powered down; only a SCSI (not preferred) drive could be created while the machine was powered up.  Note also that, as soon as you start down this path, Workstation may create a miniature version of a file for such a hard drive, even if you then abort the process -- in which case your later attempts to create that file may trigger strange results, until you investigate and delete any such runt file.
• 1.5GB RAM.  I had opted for 32-bit Ubuntu and WinXP after numerous previous hassles with 64-bit systems.  The discovery of PAE-enabled kernels meant I could go above the ordinary 32-bit limit of 4GB of RAM, so I was comfortable with this 1.5GB allocation for a single VM.  I could have gone higher, but I had almost never reached the point of using even this much.
• One single-core CPU.
• Based on my own usage, I set "Don't automatically connect" for floppy, USB devices,  or printer.
• Power:  enter full screen mode after powering on; close after powering off.
• Shared folders:  always enabled, map as network drive, make read/write only those that needed to be written to in Windows.
• No AutoProtect.
• Guest isolation:  enable drag and drop; enable copy and paste; don't enable VMCI.
• VMware Tools Updates:  use application default (currently update automatically).

Then I inserted the Windows XP CD and installed Windows XP, using a slipstreamed CD with Service Pack 3 (SP3) on it.  In my first attempt at this, I had to deal with the problem of making the VM boot from the CD.  I had just learned how to do this.  First, in Ubuntu's Terminal, I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM, and then I went to the end of that file and added bios.bootDelay = "10000" and saved the edited file.  This gave me a ten-second delay on VMware's splash screen.  So then I had time, on reboot, to read the options and choose F2 for BIOS setup.  In BIOS setup, I chose Boot, moved the CD-ROM drive up to be first in the boot sequence, and then hit F10 to save and close.  Then I installed WinXP.  The process was completely automatic, this time; apparently the latest version of VMware Workstation was able to detect my settings from the underlying Ubuntu installation.

Once WinXP was done with its basic installation process, I right-clicked on the VMware Tools icon in the system tray (i.e., the lower-right-hand corner of the WinXP desktop), chose "Open VMware Tools," and selected all three items in the Options tab, and then closed that.  To get the Windows desktop to stretch all the way across the monitor, I used VMware's View > Stretch Guest (using the menu at the top of the screen), and then returned it to View > Autofit Guest, and for some reason that did it.  I had to map my network drives after listing them in Workstation's VM > Settings > Options > Shared Folders.  Then I turned to the process of tweaking my WinXP installation.  There are some additional VM-related notes in my post on that.  When I tried to open a PDF file from within the VM, I got a Default Host Application error message.  Another post discusses that problem.

I wanted to use Acronis TrueImage to make periodic images throughout the installation process, so as to capture each working state of the system in a single snapshot.  On a standalone WinXP installation, that would have been just a matter of inserting the Acronis CD and making the backup to a separate partition.  In the VM context, though, Acronis was only willing to recognize only those partitions that were defined as part of the VM.  What I did instead, then, was to power down the VM, use Nautilus to copy the entire VM's folder to an NTFS drive, boot Acronis, and make an image of that VM folder.  (I also made a .zip of it in 7zip, just in case.)

To get the system to pause before loading Windows within VMware, so that I would have time to make a decision to adjust the BIOS or choose boot devices, I edited the individual virtual machine as described in a previous post.  Basically, I set Workstation's VM > Settings > Hardware tab > CD/DVD > "Connect at power on" and "Use a physical device" (though I was intrigued by the "Use ISO image" option).  In Terminal, I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM; and at the end of that file I added a line that said this:

    bios.bootDelay = "10000"

and that bought me ten seconds instead of one or two, when that vmware logo came up.

*** NOTE ***

At this point, I stopped developing this post.  Several other system issues had to be taken care of first, and those were superseded by non-system tasks.  When I returned to this post several months later, my purpose was just to close it down.  I had decided, by that time, to stop working on VMware within Ubuntu.  The following fragments are the other notes I had left over, in incomplete form, when I ceased working on this post.

Fragmentary notes continue as follows:

*  *  *  *  *


At some point in the process, I started getting an error message when I was trying to shut down the WinXP VM:

End Program - VMwareUser.exe
This program is not responding.

I did a search and found that virtually nobody was having this problem.  That was not a good sign.  A different search suggested that lots of people were having problems of one sort or another with VMwareUser.exe.  That was not a good sign either.  I didn't have an answer for this problem at this time.

After adding another program, Windows Explorer began flashing, refreshing itself every couple of seconds, in what appeared to be a different network drive problem.  I have written up the process of solving that in a separate post.

After tweaking the WinXP installation, I began adding programs.  I installed Copernic Desktop Search as one of those programs.  VMware Workstation treated my data drives as network drives, and Copernic regarded network drives as a sign that I was in a workplace, so I could not use their free version with VMware.  I downloaded their professional version ($40 to buy) and used it on a trial basis.  It was not able to save its index to a network drive.  Its index, I heard somewhere, would be about 10% of the total size of the files being indexed.  So if I had 100GB worth of files, I would have a 10GB index.  I definitely did not want that kind of monster sitting on my drive C.  But there seemed to be no alternative.  I decided to add a third virtual hard drive (30GB max, not preallocated) to the VM, made it drive Q, and told Copernic to save its index there.  When Copernic was done with its indexing, that drive

The only tweak that didn't seem to work was the one where I went into Internet Explorer and tried to save its Temporary Internet Files folder to some drive other than C.  It wouldn't save to a network drive.  But it also wouldn't even save to the little drive that I had created to serve as a paging file.  Possibly there wasn't enough disk space available for it there.

In the interests of improving performance, I worked through a VMware document on that subject.

Ubuntu 10.04: UDEVADM Trigger Is Not Permitted While UDEV Is Unconfigured

In the process of installing Ubuntu 10.04, I got an error message:  "udevadm trigger is not permitted while udev is unconfigured."  Trying to reboot into Windows XP on that dual-boot computer led to the same error message.  This post describes my efforts to resolve that error.

As I looked into it, I found some indications that this was due to a bug in Ubuntu.  In my case, the immediate trigger seemed to be the decision to use an "installed-software" package (as described in the main installation post) to restore many of my previously installed programs at once.  Alternately, it may have been due to the concomitant effort to set up a separate home partition.

At least one user fixed this problem by using a different kernel.  I didn't seem to have any other kernels on my machine at this point, so I started over and re-did the basic Ubuntu installation.  This time, I installed everything to the root partition.  I rebooted, copied over my backup of fstab, changed it to reflect the new root partition's UUID, and rebooted.  Having discovered that I had made some mistakes in the separate home partition process, I tried that once more, and now that worked too.  I rebooted and ran installed-software (above).  This time, I declined to erase previously downloaded .deb files.  I rebooted again.  Unfortunately, I now had that udevadm message again.  Examining it more closely, I saw that, after a minute or two, it went on to say this:

ALERT!  /dev/disk/by-uuid/xxxxxxxxxxx does not exist. Dropping to a shell!

where "xxxxxxxxxxx" stands for a UUID.  Which UUID?  I could not figure out how to do things in the shell that opened up, so I rebooted with the Ubuntu Live CD.

According to fstab, the UUID belonged to my Ubuntu programs partition.  I typed "sudo blkid" and compared its output.  Fstab was correct:  it was identifying the UUID for that partition.  So when Ubuntu would try to boot, it would not find itself.  How was that possible?  This seemed to be a GRUB problem.  Following advice, I opened /etc/default/Grub and uncommented (i.e., removed the leading # sign from) the line that read "GRUB_DISABLE_LINUX_UUID=true."

I was then supposed to run update-grub, but I didn't know how to do that from a Live CD boot.  One post said that it was possible; I needed to do so "from inside a chroot environment."  Wikipedia seemed to say that chroot means "change root"; the idea was that I would use chroot so that, when I was running a program (e.g., update-grub) as root, the "root user" doing so would be that of the hard drive, not of the CD.  A Community Documentation page told me that it was "a special directory on your computer which prevents applications, if run from inside that directory, from accessing files outside that directory . . . like installing another operating system inside your existing operating system."  In other words, I needed to use chroot and then run update-grub as the root of my Ubuntu installation.  Unfortunately, the procedure described in that Community Documentation page required me to begin by installing dchroot and debootstrap, and I wasn't able to do that.

Something made me think that Super Grub Disk, which I had forgotten about, could provide a solution.  Looking into that led me to Rescatux instead.  But then the Super Grub Disk wiki said that Auto Super Grub Disk (ASGD) was the easiest solution for a Windows user.  Working on another computer, I downloaded it.  I expected an ISO, but it was an executable (.exe) file, so I ran it.  It gave me a dialog that seemed to be wiling to install ASGD on a USB drive, so I plugged one in, designated ASGD (not SGD) and USB (not hard drive) as my options (I had to restart ASGD to get it to see the drive), and clicked OK.  After a minute, it said "Installation Complete, Reboot."  So I plugged the USB drive into the troubled computer and did that, making sure to choose USB (actually, USB-HDD) as my first boot device in BIOS.  But it said, "BOOTMGR is missing."

So now I did try Rescatux.  I downloaded it, burned it to a CD, and booted it.  Its wizard came up, and I killed it.  But then it turned out that the wizard was the main thing, though the program did have a nice interface reminiscent of BartPE, with an applications menu and so forth.  Unfortunately, I couldn't figure out how to get the wizard back, so I had to restart it.  (The instructions on the SGD wiki were incorrect, and it was apparently not possible to edit pages or become a new user of the wiki.)  This time, from the Rescatux wizard, I chose GRUB options > grub-install > run.  It auto-selected my Ubuntu partition.  But then it said, "Which hard disk to install Linux on?"  I didn't want it to install Linux anywhere.  It made me nervous.  Anyway, I didn't want it to install GRUB either; I feared that would just wipe out the Windows part of my GRUB menu and give me a new problem to fix.

I tried again, this time with Super GRUB2 Disk.  The SGD wiki advised me to enter certain commands from the prompt, but did not say how to get to a prompt.  I tried the SGD option for "Detect any GRUB2 configuration file (grub.cfg)."  It found only one and seemed to be offering to load it.  I went with that.  It ran the GRUB menu OK and that took me to the udevadm error message.  Great.  I rebooted the SGD and tried the "Enable serial terminal" option.  But that just brought me back to the menu.  Tried it again; same result.

Back to the drawing board.  I found a different Ubuntu wiki page on how to recover GRUB2 via Live CD.  This seemed more on target.  It called for booting the Ubuntu Live CD, opening Terminal, and typing "sudo blkid" to get the device where Ubuntu was installed.  In my case, it was /dev/sdb8.  So then I typed "sudo mount /dev/sdb8 /mnt."  I didn't have /boot or /var on separate partitions, so I could just go directly to these commands:

sudo mount --bind /dev /mnt/devsudo mount --bind /proc /mnt/procsudo mount --bind /sys /mnt/syssudo chroot /mntupdate-grubexitsudo umount /mnt/devsudo umount /mnt/syssudo umount /mnt/procsudo umount /mnt

Then I rebooted.  Went through the GRUB menu; still got the UDEVADM message.  Back at the starting point, I tried searching again for answers to that error message.  Following an approach that seemed to work for some people, I started by booting the system and getting to my GRUB menu.  I hit the down-arrow key to stop the clock so that I could copy down the number of the Linux kernel I was trying to install.  In my case, it was 2.6.32-24-generic-pae.  (Alternately, I could have just typed "ls /boot" as one of the following commands.)  Having already found that Ubuntu was installed on /dev/sdb8, I rebooted with the Live CD, opened Terminal, and typed this:

sudo mkdir /media/newrootsudo mount /dev/sdb8 /media/newrootsudo chroot /media/newrootapt-get updateapt-get dist-upgrade

I rebooted and sat back to watch.  No joy.  Still got UDEVADM.  I rebooted the live CD and tried a modification of those commands:  redid the first three, down through the chroot step, but then typed "sudo update-initramfs -u -k 2.6.32-24-generic-pae."  This brought several error messages:  "Unable to resolve host ubuntu" and "No such file or directory" (in connection with an automatically generated "grep:  /proc/modules" command).  I rebooted, wishing these error messages wouldn't matter -- and, woo hoo! what do you know, they didn't!  I was booting into Ubuntu.  It ran a check on my disks, and that was the end of the story!

Ubuntu 10.04 Reinstallation: Another Go

I had previously installed Ubuntu 10.04 once or twice.  This post provides a synthesis of the process, done on a Windows XP dual-boot machine.

Things to Save

The first thing to think about was, What did I want to save from my previous installation?  I was already keeping my data in an NTFS partition that WinXP recognized as D:.  I had named that partition DATA in both operating systems (OSs).  So I did not have most of my data on the root (commonly referred to with a simple slash, "/") partition containing my Ubuntu program installation.  The main exception was what Ubuntu knows as the /home partition.  (This and other Ubuntu folders, being included on a partition formatted in ext3 or ext4, were invisible to Windows.)  The /home partition was the default location for user data files.  My own files -- documents, PDFs, etc. -- were no longer there, but Ubuntu would still save various settings and other things there.  So I decided to try create a new /home partition, and copy the old /home folder's contents to the new /home partition, before reinstalling Ubuntu.  That little effort became the subject of a separate post.

Just in case, I saved my open tabs in Firefox (Ubuntu) using an extension whose name was not visible to me at this writing -- called (I believe) CopyAllURLs.  I also used the FEBE addon to save my complete Firefox setup; and since FEBE had failed in the past, I used the InfoLister addon to save at least the list of addons that I had currently installed.  I had previously saved their settings separately, for those addons (e.g., Tab Mix Plus, Forecastfox) that allowed me to do so.  I saved all of these things to my data drive, not to the Ubuntu programs drive that I was about to wipe out.  All of these steps proved to be unnecessary:  the separate /home partition (below) saved my entire Firefox setup just as I had left it.

I started up Chrome and Opera, both of which I had installed on this machine, and saved a list of their open URLs.  This, too, was unnecessary, thanks to the separate /home partition.  I had already migrated my email and contacts from Thunderbird (Ubuntu) to the Windows portable version of Thunderbird.

There was another thing to save, but I forgot until too late.  I should have run the installed-software command to make a current list of the programs I had installed on Ubuntu.  Instead, I was going to have to use the older list that I had saved some months earlier, and any programs installed since then would have to be rediscovered and reinstalled one at a time.

I should also have saved /etc/fstab.  My set of hard drive partitions had mostly not changed.  I could have just edited that instead of starting over from scratch (below).

That was pretty much all that I needed to save from the old Ubuntu programs partition that I was about to wipe out.  Most of my work was done in Windows virtual machines running on VMware Workstation, and those were on a separate partition already.  So now it was time to begin the installation.

Installation from CD

This time, I installed Ubuntu 10.04 from scratch, using the CD.  Previous inquiries had suggested that the PAE-enabled kernel would be installed automatically when installing from the CD.  (PAE allowed 32-bit Ubuntu to access RAM well beyond the 4GB theoretical limit -- apparently up to 64GB.)  By right-clicking on individual items in the partition install screen during installation, I manually designated a 30GB root ("/") partition for programs.  The installer automatically detected my previously formatted 5GB swap partition.  It seemed that people were still having problems with ext4, so I formatted the root partition as ext3.  At reboot, GRUB did say that I was installing a PAE kernel, so that was good.

Installing Software

Now I ran the second half of the installed-software command (above) to restore the set of programs that I had installed on Ubuntu at various points.  This involved using Nautilus to put a copy of my installed-software list someplace accessible (I chose my Desktop), using "cd ~/Desktop" as the short way of getting to the desktop, and then typing the necessary commands:

sudo dpkg --set-selections < installed-software
sudo apt-get install dselect
sudo dselect

This gave me a menu, from which I chose option 3, "Install and upgrade wanted packages."  It did so.  It took about an hour.  During the process, it asked "Do you want to erase any previously downloaded .deb files?"  My search yielded no clear answer to this question.  I guessed, from a couple of things I saw in that search, that this was like the question that came up in some Windows installations (in Microsoft Office, perhaps), where you would have the option of keeping downloads on the hard drive to make future fixes or upgrades faster, at the expense of consuming additional disk space.  I tried the Yes option.  It paused for a minute and then put me back at the menu.  So I guess it deleted some .deb files.  Anyway, the installed packages included ntfs-config, so now I could run that ("sudo ntfs-config"), so that Ubuntu would recognize my NTFS (Windows) partitions and put appropriate entries in /etc/fstab.  So then /home would be recognized on reboot.

Unfortunately, something in the install-software process screwed up my system, leading to a "udevadm" error message and a whole separate post.  But then, when I rebooted, I had another problem.  I was looking at a nearly blank screen.  It just showed the name of Ubuntu across the top ("Ubuntu 10.04.1 LTS P4 tty1," where P4 was the name of my computer) and then gave me a simple login prompt:  "P4 login."  I wasn't sure what to search for, to solve this problem, so I booted with the alternative installation CD and chose the "Rescue a broken system" option.  Ultimately, it gave me two basic options:  either reinstall GRUB or execute a shell in my Ubuntu program partition (in my case, /dev/sdb8).  I had no idea what to type at the prompt, and I didn't seem to be having a GRUB problem, so I tried a search; but it turned up stuff dealing with monitor problems.  I tried another search and came across the idea that I could just type "startx" to open the graphical user interface (GUI), so I rebooted, entered my username and password at that prompt, and then typed startx.  But this gave me some error messages:  "Failed to open device," "No valid modes," and "Screen(s) found, but none have a usable configuration."

Basically, it seemed that the installed-software process had messed up my system.  So I started over, installing Ubuntu from scratch, and this time I didn't use the installed-software option.  I had to go back through the process of setting up my separate /home partition, and then I worked manually through the installed-software process.  That entailed setting up my repositories.  After that process, some programs were still not installed.  Drawing upon my previous installation and its follow-on comments (as well as notes in a few other posts), I used System > Administration > Synaptic Package Manager to install acroread, adobe-flashplugin, boinc, dvgrab, fdutils, gparted, mplayer, nautilus-open-terminal, ntfsprogs, p7zip-full, sysinfo, ubuntu-tweak, unetbootin, and webhttrack.  Then I installed several programs that I had downloaded separately, on the assumption they were not available via Synaptic.  These included VMware Workstation 7, which I installed, as I had learned to do, by typing "sh VMware-Workstation-Full-7.1.0-261024.i386.bundle" in the folder containing that downloaded bundle file.  The simple "sudo sh" prefix was also adequate for installing my separate .bin downloads (i.e., GoogleEarthLinux.bin).  I installed Beyond Compare, Opera, and Google Chrome by just double-clicking on the .deb downloads.

Settings and Adjustments

Creating the separate /home partition had preserved most of my Nautilus settings, but I still had to tweak a few of those manually.  It had not saved my monitor driver settings, so now I went into System > Administration > Hardware Drivers, searched for available drivers and, for my machine, found NVIDIA accelerated graphics driver (current version) > Activate. This, like other installation and activation steps, would work only when there was no other Synaptic or software installer running.  I rebooted to activate the hardware driver.  Unfortunately, I was still getting some bad ghosting.  Tightening my video cable connectors solved the problem.

Most of my newly installed programs did not require immediate configuration.  To configure BOINC, I went to Applications > System Tools > BOINC Manager > Next > Choose a Project > World Community Grid > Next, and then went into Advanced > Settings to adjust my preferences.

GRUB2 had lost the setting by which it would remember which operating system I had booted last, and would reboot that one instead of defaulting to Ubuntu, so I typed "sudo gedit /etc/default/grub"; I changed one line to say GRUB_DEFAULT=saved instead of GRUB_DEFAULT=0; I added another line, right after it, that said "GRUB_SAVEDEFAULT=true"; I saved and closed that file; and then I typed "sudo update-grub."

Following a previous post, I pruned the list of entries shown in the GRUB2 menu at bootup.  First, I typed "sudo gedit /etc/grub.d/10_linux" and added a line, immediately after the comments section at the top, that said "GRUB_DISABLE_LINUX_RECOVERY=true" (without quotes, as always).  That would prevent me from seeing the "recovery" versions of Linux kernels in that menu.  At the end of that same file, I searched for the place that had these two lines:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
done

and changed it by inserting another list line between those two:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
list=`version_find_latest $list`
done

(Note that backticks ( ` ) are not the same as single quotes ( ' ) in such files.)  This, I hoped, would show me just the one or two most recent Linux kernels.  Finally, I saved and closed 10_linux and modified its companion file with this command:  "sudo chmod -x /etc/grub.d/20_memtest86+."  This command would hopefully prevent me from seeing the memtest options in the GRUB2 menu.  I rebooted and confirmed that it worked.

Other settings did remain intact via the preserved /home partition.  Unlike the steps described in the previous installation and in another tweak post, I did not have to make manual adjustments to prevent icons for mounted drives from appearing on the desktop.  My previous list of programs that should run at startup remained intact.  Gedit was still my default crontab editor.  The permissions giving me access to various partitions as ordinary user, not root, were still in place.  My VMware settings seemed to have been preserved, except for what may have been a few new root-level settings in the new version of VMware Workstation that I had just installed.

When these steps were complete, I ran Update Manager one last time, rebooted, and confirmed that everything looked good.  Then I rebooted with a CD and made an Acronis disk image on a separate partition.  Done!

VMware Workstation 7: Improving Performance in 32-bit Ubuntu 9.10 (Karmic Koala)

I was in the process of tweaking an installation of x32 Ubuntu 9.10, and ran into some VMware performance issues.  Specifically, in VMware Workstation 7, I found that one of my virtual machines (VMs) performed much more slowly under 32-bit Ubuntu than it had performed under 64-bit.

To improve performance, I tried a couple of things.  I shut down the VM I was using, closed Workstation, typed "sudo vmware," and went into Workstation's VM > Settings > Hardware tab > Processors.  I had set it at 2, because I was using a dual-core processor, but I vaguely recalled that that had seemed slower at one point in the past, so I changed it to 1 processor.  I also increased Memory from 1000MB to 2000MB.  Also, while I was running Workstation as root, I went to Edit > Preferences > Memory.  I left Reserved Memory at 2500MB and changed Additional Memory to "Allow some virtual machine memory to be swapped," which as I recalled was the original setting.  I also thought that I might have been able to speed up the VM somewhat if it was smaller:  this particular one was 35GB, having been converted from a larger WinXP partition.  With these changes in place, I closed out of Workstation as root, started Workstation normally, and tried the VM again.  It was still very slow -- if anything, worse than before.  Some of this slowness could have been due to other hard drive activity.  I had recently installed Google Desktop, and it was indexing my hard drive throughout the time when I was writing this post.  But at this same time, another VM, set to 1 processor and only 1000MB of RAM, worked acceptably.

To speed things up further, there were numerous tweaks that would supposedly improve Ubuntu performance.  One speedup option was to buy a solid state drive (SSD).  This, it was said, would yield "a remarkable change in system performance - boot time and program startup times are drastically reduced. I highly recommend the investment - I have never before seen a single hardware change that affected performance as much as an SSD."  SSDs that would be large enough (30GB+) were currently at $150 and more, so that was something to think about for the future, as prices came down.  Getting an SSD would apparently call for some additional adjustments.

I ran a search to see if I could use the rest of my system's memory as a RAM disk.  This didn't seem to be a very common procedure.  But one post said it was simple.  The dominant approach seemed to be to tell Ubuntu to load its /tmp temporary files folder into RAM at startup.  There were different types of Ubuntu RAM disks.  The one called tmpfs seemed optimal.  The general idea seemed to be that you would set up tmpfs at a special location known as /dev/shm.  According to Kevin VanZonneveld, "The standard /dev/shm grows automatically as more space is needed, but is by default limited to half of your physical RAM. If you have 2GB, it can grow to 1GB at most."  There seemed to be ways to change that; but since I figured I'd typically have total RAM of 6GB to 8GB in my system, 50% of RAM seemed fine.  For future reference, there were ways to speed up Firefox by using tmpfs, but I hadn't noticed as much of a need for that, especially outside of the VMs.  What seemed most immediately promising, for my purposes, was to use /dev/shm for VMware specifically.  After some hunting, I found a website for VMware Server, but I wasn't sure whether I should try using its suggestions in Workstation.  I learned that KVM is an open source competitor with VMware but is still rather complex.  Then I noticed that someone said that a Physical Address Extension (PAE) aware kernel would allow 32-bit Ubuntu to use more than the (theoretically 4GB, but practically) 3GB RAM limitation.  I checked that out and concluded that 32-bit PAE performance was not going to be much better per se than plain 32-bit (and both would remain far below 64-bit performance), but neither would it hurt (unless I turned out to be one of those users who had problems with e.g., the mouse or graphics).  There was supposedly some performance reduction if you installed it in the standard way; the alternative was to build a custom kernel, which was beyond my time and abilities at that point.  I had just made an Acronis TrueImage backup, so I decided to try the standard approach, in its latest version.  First, I went to Synaptic and installed linux-generic-pae and linux-headers-generic-pae.  This did its thing for five minutes or so, and then said it needed to restart.  When the machine rebooted and got to GRUB, it showed me a new item:  "Ubuntu, Linux 2.6.31-19-generic-pae."  I selected that.  The BIOS told me, at boot, that I had 6GB of RAM.  When Ubuntu loaded, my previously opened windows were still in place (due to settings described in the previous post), but not VMware.  Instead, I had a dialog that said this:

VMware Kernel Module Updater

Before you can run VMware, several modules must be compiled and loaded into the running kernel.

So I went with that.  Meanwhile, I typed "free -m" and it reported that I did indeed have a total of 6050 of memory.  I wondered whether this would make any difference in VMware.  When the modules were done loading, I started VMware as root and increased the VM's allocation from 1000MB to 1500MB.  I also changed Additional Memory back to"Fit all virtual machine memory into reserved host RAM" and increased Reserved Memory to 5000MB of the 5472MB available to VMs.  Also, I changed the individual VMs to use 1500MB each.

Then I powered on the VM that had been working adequately before.  There was no question that it was much snappier.  With that one running, I powered up the other one, the one that had started the investigation.  So the additional memory definitely was available:  I had two machines running, where before I could only run one.  Now that I had two VMs up, the first VM, the better performer, was running more slowly.  The other one was still slow, but definitely was running better than before.  As before, the new Ubuntu kernel's audio started as muted, so I had to unmute it and turn it up, but then audio in both VMs worked.  There was stuttering in the second, larger VM.  To get the best performance, I turned off one VM and left just one running.  The memory enhancement had still not put me back to where I had been with 64-bit Ubuntu and 64-bit Workstation at their best, but if I got greater reliability and acceptable performance, that would be OK for now.  I did not pursue this further, though, because at about this time I began the process of upgrading to Ubuntu 10.04.