Adobe Acrobat Becomes Excessively Disability-Aware

I was using Adobe Acrobat 9 in Windows 7.  Suddenly it developed a sensitivity to diversity issues, particularly in the area of disability.  That is, it started offering accessibility services that I didn't want or need.  One message come up when I printed a .PNG image file to PDF.  As soon as Acrobat opened the PDF, it said this:

This page contains only an image of a scanned page.  There are no text characters.  Would you like to run character analysis to try to make the text on this page accessible?

I clicked the "Do Not Show Again" box and then OK.  The only alternative was Cancel, and I was afraid that would be construed as "please ignore what I just said."  Wrong guess:  it ran OCR on the page, which in this case meant it completely screwed it up.  I printed it again.  This time it didn't ask.  Fortunately, it seemed to be ignoring what I had just instructed it to do (i.e., run OCR without asking):  it didn't run OCR.  Another thing it did, when I printed an HTML page to PDF, was to flash a screen that said this:

Content Preparation Progress

Please wait while document is being prepared for.

At least I think that's what it said.  It flashed by pretty quickly.  It didn't say what the document was being prepared for.  But the result was a crappy-looking PDF.

I guessed that I must have hit a funky key combination that turned on some kind of accessibility feature.  I hadn't started this post when the problem first arose, but something had caused Acrobat's Accessibility Setup Assistant to spring into action.  There didn't seem to be any option to shut it off, at least not on the dialog that popped up.  I ran a search.  In one thread, someone commented that this sort of thing happened only when they had Speech Recognition turned on.  In Acrobat, I went into Edit > Preferences > Accessibility.  I unchecked everything and then printed that HTML page again.  No improvement.  Another person in that thread suggested going to C:\Program files\Adobe\Acrobat 8.0\Acrobat\plug_ins and renaming Accessibility.api to be Accessibility.old.  I tried that.  Now I got a new message:

No Screen Reader Support

This version of the Adobe Reader does not support screen readers.  Information about downloading a version with screen reader support is available at http://www.adobe.com/go/reader_download

Apparently the step of making the Accessibility.api file unavailable was to persuade the system that Acrobat was not available for this purpose, and it should use Adobe Reader instead.  In that case, it sounded like the instructions to use accessibility settings might be coming from Windows, not from Acrobat.  I clicked the "Do not show this message again" box and tried printing the HTML page again.  No, it still displayed the page in Acrobat, not Reader -- which, when I checked in Control Panel > Programs and Features, wasn't even installed on my system.  I decided that renaming Accessibility.api to be Accessibility.old had not solved the problem, so I changed it back.  I did take a look, nonetheless, at Control Panel > Ease of Access Center (formerly Accessibility).  I went into the "Make the computer easier to see" option.  The only thing turned on there was the first option, "Turn on or off High Contrast when ALT + left SHIFT + PRINT SCREEN is pressed."  I turned that off, clicked Apply, and tried printing the HTML page again.  No, still got lousy output.

I couldn't see anything else obviously wrong in the Ease of Access center, so I went back to that discussion thread for more ideas.  But there weren't any.  A How-To Geek webpage gave me the idea that maybe the full message (above) was, "Please wait while the document is being prepared for reading."  This page said that renaming or removing Accessibility.api would kill that "Please wait" message.  And that might have been true; I hadn't looked specifically at that part.  But that wasn't my main objection. My main objection was that I was getting crappy PDFs.  And when I put it that way, I realized that it might be a problem with the PDF printer.  I was using Bullzip.  Was there an option that had gotten set wrong somehow?  In Bullzip's Options > Image tab, the resolution was set to only 150.  Was that 150 dots per inch?  If so, that could explain part of the problem.  I set it to 300 and tried again.  No change.

Participants in another thread, describing similar problems, seemed to say that the problem arose, for them, when they used Acrobat's speech tools.  I wasn't familiar with them, but thought I might take a look.  I went into Acrobat with no document open.  In Advanced > Accessibility, the only option that wasn't grayed out was Setup Assistant.  I went in there and selected "Set all accessibility options" > Next.  This seemed to be taking me through the same options that I could have gotten via Edit > Preferences.  I noticed that "Disable text smoothing" was checked, so I unchecked it; text smoothing sounded good.  In the next screen, I left it as I found it, with only one thing selected, "Infer reading order from document."  In the screen after that, the only thing selected was, again, the default, "For large documents, only read the currently visible pages."  In the screen after that, "Disable document auto-save" had somehow gotten checked.  I wanted auto-save, so I unchecked it.  Evidently the funky key that I had accidentally hit, whatever it was, had told Acrobat that I had some kind of disability, and therefore it launched into a whole menu of disability assumptions.  Anyway, the only thing I left checked on that page was "Reopen documents to the last viewed page."  By this point, I was seeing that, yes, I could have achieved these same changes by going into Edit > Preferences, but the one-size-fits-all disability assumption seemed to cherry-pick options from a variety of different Preferences submenus.  This seemed to be a better way of detecting what it had messed up.

Anyway, that was the last screen.  I clicked Done, and tried printing my HTML document again.  This time it was better.  The font looked good.  So part of the solution was to go through the Accessibility Setup Assistant and reverse some of its settings.  I was still getting that message, "Please wait while document is being prepared for."  I renamed Accessibility.api to be Accessibility.old again and reprinted the HTML document.  No more "prepared for" message.  So the other part of the solution was to kill Accessibility.api.  Ah, but now I had a new problem.  When I tried to go into Edit > Preferences, I got an error:  "Failed to load an application resource (internal error)."  I restarted Acrobat and tried again.  Same error.  Apparently it couldn't go on living without its Accessibility.api.  I renamed Accessibility.old back to Accessibility.api and tried again.  Yes, now I could go into Preferences.  So it seemed I might have to cope with that "document is being prepared for" message.

One poster in that thread seemed to say that, if Microsoft Magnify was turned on when Acrobat started, Acrobat would detect it and would assume that the user had a disability.  This was an interesting possibility.  Was Acrobat detecting some running program and inferring disability from that?  I went into Start > Run > taskmgr.exe > Applications tab and took a look.  Nothing obvious.  Well, the Ease of Access Center was open.  I closed that and tried printing my HTML page.  Nope, that wasn't the answer; I still had the problem.  I right-clicked on an empty spot on the Taskbar and went into Taskbar tab > Customize.  I looked at the System Tray utilities shown there.  A couple of possibilities but, again, nothing obvious.  There was a troublesome utility that I'd had a hard time deleting, DropCommand, but I was able to delete it now.  I doubted it was the problem.

I rebooted into Safe Mode, thinking this would tend to simplify the picture somewhat:  fewer programs would be loaded and running.  Instead, Safe Mode gave me a new cluster.  No PDF printers installed.  I didn't know that about Safe Mode.  I tried installing Bullzip, but got an error when I got to the part of installing the Ghostscript part:  "Unable to register the DLL/OCX:  RegSvr32 failed with exit code 0x5."  I started Acrobat, but within a few seconds I got an error message there too:

Licensing for this product has stopped working

You cannot use this product at this time.  You must repair the problem by uninstalling and then reinstalling the product or contacting your IT administrator or Adobe customer support for help.

So, OK, at least this gave me an opportunity to reboot.  Back in Normal Mode, thankfully, I did not get a licensing error message.  So then, to return to the question:  what programs might be running that would trigger a belief, in Acrobat, that I needed a bunch of disability options to be installed without asking me?

I wasn't sure how to get an answer to that, short of a potentially very time-consuming process of eliminating programs, one by one, and rebooting, and seeing what happened.  This was problematic now because, for some reason, when I tried to print my HTML page, I didn't have any problems.  So it seemed that I might have fixed the symptoms, at least.

Instead, a day or two later, there were new developments.  Now Acrobat's toolbars were no longer functioning properly.  They had been erratic in Acrobat 8; less so in Acrobat 9; but now the Crop option was gone, and other toolbar settings would be disregarded.  I tried a repair:  Control Panel > Progams and Features > select Adobe Acrobat > Uninstall/Change > Repair.  This repair called for a reboot.  I'm not sure how that turned out; my notes are weak at this point.

I also had another problem.  When I opened a newly downloaded PDF, I got this message:

Reading Untagged Document

This 133-page document is untagged and must be prepared for reading.  While the document is being analyzed, your assistive technology will not be able to interact wiht this application.

I canceled out of that and went through the steps I had figured out so far:  change things back the way I wanted them in Advanced > Accessibility > Setup Assistant.  Then I reopened the PDF.  Still got that same "Reading Untagged Document" dialog.  I had that DropCommand program installed on that machine too, so I deleted it.  There wasn't an uninstall option that I could see.  As on the other machine, I had to move the executable to the Recycle Bin folder and then delete it after a reboot.  A couple of days passed before I did that reboot.  The problem was still there.

This problem was one of several, along with some major hardware changes, that prompted me to give up and reinstall Windows 7.  My best guess was that this problem was related to a sticky Shift key problem, and that several such issues ultimately stemmed from a failing KVM switch.

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.

Win7RegEdit-x64.reg

This is a companion to the Win7RegEdit.reg file.  That one is for 32-bit Windows 7; this one is for 64-bit.  There are further comments in that post and in the Windows 7 Tweaked Installation post.  It bears repeating that inappropriate tinkering can screw up a system.

Windows Registry Editor Version 5.00

; Run Ultimate Windows Tweaker first.  This adds options not available there.
; More info & restore options in 32-bit version of this file.

; ************* WINDOWS EXPLORER *************

; Disable libraries
[-HKEY_CLASSES_ROOT\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{031E4825-7B94-4dc3-B131-E946B44C8DD5}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{2112AB0A-C86A-4ffe-A368-0DE96E47012E}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{491E922F-5643-4af4-A7EB-4E7A138D8174}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{7b0db17d-9cd2-4a93-9733-46cc89022e7c}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A302545D-DEFF-464b-ABE8-61C8648D939B}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A990AE9F-A03B-4e80-94BC-9912D7504104}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel]
“{031E4825-7B94-4dc3-B131-E946B44C8DD5}”=-
; Turn off Details pane (at bottom of WinEx)
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Modules\GlobalSettings\Sizer]
"PreviewPaneSizer"=hex:45,00,00,00,00,00,00,00,00,00,00,00,0c,02,00,00
; Set Documents folder template as default
[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell]
"FolderType"="Documents"
; Add context menu option to open files with Notepad
[HKEY_CLASSES_ROOT\*\shell\Notepad]
@="Open with Notepad"
[HKEY_CLASSES_ROOT\*\shell\Notepad\command]
@="notepad.exe \"%1\""
; Disable Windows from asking "Do you want to open this file?"
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Download]
"CheckExeSignatures"="no"
"RunInvalidSignatures"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments]
"SaveZoneInformation"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Associations]
"LowRiskFileTypes"=".zip;.rar;.nfo;.txt;.exe;.bat;.com;.cmd;.reg;.msi;.htm;.html;.gif;.bmp;.jpg;.avi;.mpg;.mpeg;.mov;.mp3;.m3u;.wav;"
; Disable annoying web service dialog for opening files
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoInternetOpenWith"=dword:00000001
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoInternetOpenWith"=dword:00000001
; Disable Windows 7 built-in CD burning
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoCDBurning"=dword:00000001

; ************* START MENU, TASKBAR, AND THUMBNAILS *************

; Make Aero Peek happen quickly (200 milliseconds; default is 500)
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
"DesktopLivePreviewHoverTime"=dword:00000200
; Make Aero taskbar thumbnails show contents quickly when hovering
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
"ExtendedUIHoverTime"=dword:00000200
; Increase Start Menu display speed (default is 400)
[HKEY_CURRENT_USER\Control Panel\Desktop]
"MenuShowDelay"="200"

; ************* FILE LOCATIONS *************

; Point to W for customized Start Menu and Programs
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
"Administrative Tools"="W:\\Start Menu"
"Programs"="W:\\Start Menu\\Programs"
"Startup"="W:\\Start Menu\\Programs\\Startup"
"Start Menu"="W:\\Start Menu"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]
"Programs"="W:\\Start Menu\\Programs"
"Startup"="W:\\Start Menu\\Programs\\Startup"
"Start Menu"="W:\\Start Menu"
; Point to Current folder for Music, Video, Pictures, etc.
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
"My Music"="D:\\Current"
"My Pictures"="D:\\Current"
"My Video"="D:\\Current"
"Personal"="D:\\Current"
"{374DE290-123F-4565-9164-39C4925E467B}"="D:\\Current"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]
"My Music"="D:\\Current"
"My Pictures"="D:\\Current"
"My Video"="D:\\Current"
"Personal"="D:\\Current"
"{374DE290-123F-4565-9164-39C4925E467B}"="D:\\Current"
; Point to X:\Cache for cookies, cache, etc.
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
"Cache"="X:\\Cache\\Temporary Internet Files"
"Cookies"="X:\\Cache\\Cookies"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]
"Cache"="X:\\Cache\\Temporary Internet Files"
"Cookies"="X:\\Cache\\Cookies"
; Customize default places bar in Win7's common file dialog box
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\comdlg32]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\comdlg32\Placesbar]
"Place0"="MyDocuments"
"Place1"="Recent"
"Place2"="D:\\Career"
"Place3"="D:\\Personal Projects"
"Place4"="W:\\Start Menu\\Programs"

; ************* INTERNET EXPLORER *************

; Specify IE download directory
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer]
"Download Directory"="D:\\Current"
; Force IE to launch shortcuts in a new window
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"AllowWindowReuse"=dword:00000000
; Disable “Speed up Browsing by Disabling Add-ons” popup notification
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Ext]
"DisableAddonLoadTimePerformanceNotifications"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Ext]
"DisableAddonLoadTimePerformanceNotifications"=dword:00000001

; ************* LOGIN, LOGOUT, SHUTDOWN *************

; Save settings on exit
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoSaveSettings"=dword:00000000
; Disable automatic restart after crash so you can see error messages
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]
"AutoReboot "=dword:00000000
; Manually generate a crash by hitting RightCtrl-ScrollLock (twice on the latter)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\i8042prt\Parameters]
"CrashOnCtrlScroll"=dword:00000001
; Undo:  "CrashOnCtrlScroll"=dword:00000000

; ************* UNBLOCK MICROSOFT OFFICE *************
; Some older files cannot be opened in Office without these fixes
; Unblock Word
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Word\Security\FileOpenBlock]
"FilesBeforeVersion"=dword:00000000
; Unblock Excel
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Excel\Security\FileOpenBlock]
"LotusandQuattroFiles"=dword:00000000
"LegacyBinaryFiles"=dword:00000000
"LegacyDatabaseAndDatasourceFiles"=dword:00000000
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Excel\Security\FileSaveBlock]
"LotusandQuattroFiles"=dword:00000000
"LegacyBinaryFiles"=dword:00000000
"LegacyDatabaseAndDatasourceFiles"=dword:00000000
; Unblock PowerPoint
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\PowerPoint\Security\FileOpenBlock]
"FilesBeforePowerPoint97"=dword:00000000
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\PowerPoint\Security\FileSaveBlock]
"FilesBeforePowerPoint97"=dword:00000000
; Unblock Corel Draw
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Graphics Filters\Import\CDR]
"Enabled"=dword:00000001

; ************* OTHER TWEAKS *************

; Remove "Shortcut" from title of shortcuts
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer]
"link"=hex:00,00,00,00
; Disable creation of Thumbs.db
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
"DisableThumbnailCache"=dword:00000001
; Disable beep on error
[HKEY_CURRENT_USER\Control Panel\Sound]
"Beep"="No"
; Increase Internet download connections to 10
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:0000000a
"MaxConnectionsPer1_0Server"=dword:0000000a
; Disable User Account Control (UAC) - probably already done some other way
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLUA"=dword:00000000
; Google Earth cache settings
[HKEY_CURRENT_USER\Software\Google\Google Earth Plus]
:: Move cache to drive X
:: Originally "CachePath"="C:\\Users\\Ray\\AppData\\LocalLow\\Google\\GoogleEarth"
"CachePath"="X:\\Cache\\Google Earth"
:: Set disk cache to 2GB and memory cache to 1GB
[HKEY_CURRENT_USER\Software\Google\Google Earth Plus\Cache]
"DiskCacheSize"=dword:000007d0
"MemoryCacheSize"=dword:000003e8

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.

Batch Converting DOC to PDF with 7-PDF Maker

I had some Microsoft Word .doc files.  I wanted to convert them to PDF.  I wanted to be able to do this from the command line, so as to reach into different folders and process large numbers of them at once.

I went into Softpedia and did a search.  It came up with numerous free programs for this purpose.  I chose 7-PDF Maker.  It had a pretty good rating, as Softpedia programs go (4.0 stars; 16,001 downloads), and it did offer a command-line option.  I also downloaded its manual.  (It had a real manual!)

Once 7-PDF Maker was installed, I searched for its command-line executable, 7p.exe.  I put a copy of it into D:\Workspace (i.e., the folder where I was working).  That way, my commands that referred to 7p.exe would know where to find it.  There were other ways, but this was simplest, and 7p.exe was not a filename that would get confused with the ones I wanted to convert.

I opened a command window in D:\Workspace and typed "7p /?" to see what the command line options were.  Basically, it seemed, I could save the DOC as a PDF with a command as simple as "7p D:\Workspace\File.doc."  The /? instructions seemed to be saying that I had to specify an absolute path for the source file (i.e., not just "File.doc" without the drive and folder information).  I was not sure whether that was necessary with a copy of 7p.exe in the working folder.  There was also an option to save the resulting PDF to a different folder (e.g., "7p File.doc D:\Workspace\Output").  In addition, I could use wildcards.  7p.exe D:\Folder\*.doc would convert all doc files in Folder to PDF.  The same command with *.* would convert all supported files to PDF.  There were many supported filetypes (manual p. 18), including Word, WordPerfect, OpenOffice, Excel, PowerPoint, and various image formats (e.g., BMP, TIF, JPG, PNG).

There were also options for overwriting and recursion (i.e., working down through subdirectories).  In both cases, the default was false (i.e., don't recurse, don't overwrite).  The default was all I needed, so I did not investigate the exact syntax.  But it appeared that one instance of the word "true" on the command line would be construed as an instruction to recurse.

I gave it a test run with x.doc.  The command I used was simply "7p x.doc."  That gave me an error, so I tried "7p D:\Workspace\x.doc."  That gave me a different error:  "Variante referenziert kein Automatisierungsobjekt."  One translation was, "Variant does not reference an automation object."  Did this mean that x.doc was not a convertible DOC file?  Or that I should have been running this in the 7-PDF installation folder on drive C?  I tried the latter with an absolute path (i.e., not just "7p x.doc").  Same "Variante referenziert" error.

I tried opening x.doc in Word.  Oh.  Now I understood.  It was called a DOC file, but it was actually just a text file with a DOC extension.  But the manual said that text files were supported.  Maybe the .doc extension was confusing 7p?  I changed it to x.txt and tried the original approach of running the command in D:\Workspace rather than in the installation folder on drive C.  Specifically, I tried just "7p x.txt."  It said, "URL seems to be an unsupported one."  Maybe it was the wrong kind of text file.  Whatever; I used a text to PDF converter for them instead.

I did not proceed further with 7-PDF because, at this point, I found an alternative I liked better.  Not to say that 7-PDF was a bad program; it just was not working really well for me at this point.

Windows 7: "Access Denied" on the Command Line When Using FIND

I tried to run a FIND command in the CMD (sometimes called the DOS) box in Windows 7.  I got an error message:

Access Denied - D:\FOLDER\SUB FOLDER

This was bizarre.  I had been using the command line in this Win7 installation for months.  Well, something had apparently changed.  I got this message regardless of whether I used my pre-installed "Open Command Window Here" right-click option in Windows Explorer or the Administrator Command Box option I had created in the Start menu.

A search led me through various possible solutions.  I tried especially to tweak the permissions for the entire partition and for the individual folder via right-click > Properties > Security tab > Advanced > Owner tab > Edit > select Administrators and check "Replace owner on subcontainers and objects," and to play with other tabs and settings in that vicinity.

One option I hadn't seen previously was to open the Local Group Policy Editor (Start > Run > gpedit.msc) and go into Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > right-click on "User Account Control:  Behavior of the elevation prompt for administrators in Admin Approval Mode" > Properties > Elevate Without Prompting.  But I already had that selected.

That writeup raised the question, though:  had I not completely disabled User Account Control (UAC)?  As advised, I went into Start > Run > Regedit and navigated to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System.  There, I right-clicked on EnableLUA and verified that the value was zero.  Nonetheless, I exported the tweak, extracted the relevant lines from the REG file, and added them to my Win7RegEdit.reg file for future installations, just to be sure.

When I was in Permissions (via Windows Explorer folder right-click > Properties > Security tab > Edit), I noticed that the permissions checkboxes were checked but greyed out.  I couldn't change them.  Was I somehow not in the right account?  A search led to a proffered batch file (Permissions.zip) that read as follows:

@echo off
title File/Folder Permissions
echo.
echo.             BY KAOS - Windows 7 Forums
echo.
echo.
set /p a=Enter Path Of File/Folder:
echo.
set /p b=User Name:
echo Type "deny" = remove access OR type "grant" = allow full access
set /p c=Permission Type:
echo.
echo.
echo.
if %c%==deny goto lock
if %c%==grant goto unlock
if %a%==menu goto start2
if %b%==menu goto start2
if %c%==menu goto start2
:lock
cacls %a% /e /d %b%
cls
exit
:unlock
cacls %a% /e /g %b%:f
cls

The gist of this batch file seemed to be that I could try a CACLS command of this form:  cacls [folder path] /e /g [username]:f, where /e meant "edit," /g specified the user, and :f gave full control.  So, in my case, what username would I use?  Control Panel > User Accounts said that I had set up my system so that the only options were Ray (Administrator) and Guest (turned off).  Maybe this was the problem:  I had been thinking in terms of the Administrator account rather than the Ray account.  So, OK, I tried typing this on the command line, to grant full control to the whole drive:

cacls D:\ /e /g Ray:f

In response to that command, I got a short message:  "processed dir: D:\.  Did that mean champagne?  I retried the command that had given me the "Access Denied" error.  No, still denied.  Alright, how about same command, different user:  Administrator.  Same output.  Still denied.  Baffling!

I ran across a post that said something about turning off simple file sharing and permissions, and then permissions.  It raised a question:  was there a way to reset permissions to the default, and start over?  For the drive (i.e., right-clicking on D: in Windows Explorer), I went into Share with > Advanced sharing > Sharing tab > Advanced Sharing.  I unclicked Share This Folder > Apply.  I got a note indicating that I had some files currently opened, and they would be closed.  I clicked Yes > OK > Close.  This, in itself, didn't have any effect on another try of the FIND command; still denied. 

I had recently gotten an indication that the Recycle Bin on drive D was corrupted.  I had said go ahead and empty it.  That message had recurred.  I had also been getting bothersome messages when I tried to move or delete folders, telling me that these folders were shared and confirming that I really wanted to do what I had said I wanted to do.  It seemed that these problems might be related.  But how, and what could I do about it?

I found a Windows XP article from 2002 that said, "If you don't have a thorough understanding of the various permissions and their relationships, it can be nearly impossible to sort out a permission problem and find a solution."  So I could see how Windows 7 was a direct descendant from Windows XP:  both could make it impossible to get any work done.  The article said that there was a difference between sharing permissions and NTFS permissions, and that the more restrictive one wins.  So if I wanted to grant full control to everyone for everything, I had to do that in two different right-click > Properties tabs:  the Sharing tab and also the Security tab.  But it really looked like I had done that, over and over again.

Ah, but now I saw a new problem.  In the Security tab, I saw that I had a little red circle with an X in it, next to the Administrator group.  There was no right-click option to explain it.  I guessed that the problem was that I had entered the wrong CACLS command, regarding Administrator rather than Administrators (plural).  So that was interesting.  I clicked on Edit, selected Administrator, and clicked Remove.  Then I re-ran that CACLS command with a reference to Administrators, this time, instead of Administrator.  But still no joy on my FIND command:  Access denied.

So anyway, as I was saying, it did seem that I had given full control to almost everyone listed in the Security tab.  I mean, literally, Everyone:  I had an entry for them, and they had full control, and so did SYSTEM, Ray, and Administrators.  But not Authenticated Users, and not plain old Users.  Who the hell were all these people, anyway, and why did we all need to have so many kinds of access to my computer so that I could get work done?  (Sigh.)  Wiser minds knew; I did not.  Anyway, I went ahead and gave full control to my whole world to everyone and his brother, Users and all.  And still the godforsaken command did not run.

And, by the way, at this point I searched in vain for those greyed-out permissions boxes I had seen earlier.  Evidently I had altered something significant, in all this screwing around.  Not so significant as to actually let me get any work done, but significant certainly in the sense that I could no longer detect greyness when I searched therefor.  Not in the Security, nor back in the Sharing tab.  Speaking of which, I now saw that my reestablished share of drive D now had permissions only for Everyone.  Did Everyone include me and all the other Administrators and Users and Authenticated Users of my home system (I was living alone), or did I need to add the whole gang back to my computer?  Not sure.

It occurred to me that I did have a solution.  It was called System Restore.  But, alas, the mere fact of telling Windows to keep system restores, accompanied by weekly checking to make sure that the task was really running as scheduled, did not necessarily mean that I would actually have recourse to any system restore points, other than the one created that very morning.  Apparently Windows was not content with the 10GB of disk space I had set aside for this purpose.  Fortuitously, I did have an Acronis drive image from a week or so earlier, and so, without further ado, I wiped the drive and restored that.  Did there exist any further difficulty?  Yes, there did.  My Acronis backup was too recent.  Apparently this problem had lurked for days and/or was not only, or primarily, a matter of drive C (stored in Acronis) as distinct from drive D (not backed up in Acronis).

I tried a different command that, I knew, I had run within recent days:  DIR.  It ran.  Now, why would DIR run and FIND not run?  FIND took a look inside files; were my permissions of some type not reaching into the files?  I right-clicked on the files in question.  They didn't have sharing or security options collectively; I had to click them one at a time to get a Security tab.  It said everyone had full control.  The Advanced > Owner tab option said the owner of at least one file was Administrators.  Anyway, the CACLS command was supposed to take care of user accouint issues.

I tried the same FIND command on another computer of virtually identical configuration.  It, too, provided a FIND error.  A search led to a brilliant insight:  my command was wrong.  I was trying to use FIND on a directory, when it only works on files.  I had to make one change:  I had to add a star (asterisk) to the end of my search.  The FIND command worked without error when I did it this way:

find /i /c "X-Message-Delivery:" "D:\Folder\Sub Folder\*"

Solution:  operator error.  Case closed.

Windows 7: Assigning Process Priorities to Prevent Slowdowns

I had some programs that slowed down my system to the point that I could barely get any work done.  Examples included Beyond Compare (sometimes) and GoodSync (often).  These programs were not usually urgent; I would have been happy with letting them run at a slower pace, so that I could continue to use the machine in a more or less normal way.  This post describes my search for tools that would give me some control over the demands that those programs would place on my system.

The existing tool for this purpose, Windows Task Manager (available via Ctrl-Alt-Del > Start Task Manager, or via Start > Run > taskmgr.exe), would give me information about various processes.  Many other programs -- including various gadgets and other sorts of monitoring tools -- offered that.  A search led to Process Explorer and System Explorer Portable, which CNET and Softpedia portrayed as popular, highly rated replacements for Task Manager.  For basic system resource information, I was presently using (and liked) Moo0 SystemMonitor, and wasn't too interested in adding more of that right now.

What I was more interested in was actual control of processes.  Evidently it was possible to adjust process priorities manually in Task Manager, and perhaps in Process Explorer and/or System Explorer Portable; but it seemed that this would work only as long as processes were running. In other words, it seemed that the Task Manager manual setting would have to be recreated every time a program was shut down and restarted.

Further investigation led to utilities that would apparently allow me not only to adjust priorities, but to have my adjustments be remembered.  Programs I encountered at this point included Prio, Process Lasso, IO Priority, and Process Hacker. Softpedia searches indicated that Project Lasso was commercial, and had nothing for IO Priority.  I had seen a few very positive comments about Prio, so perhaps it was up and coming; but it was not a major player at either Softpedia or CNET. Those two sources also disagreed as to whether I was getting a free or trial version.  On both CNET and Softpedia, Process Hacker seemed to be the leading tool for process adjustment.

The CNET download gave me both .bin and .exe versions of Process Hacker.  I was more interested in a portable version, so I unzipped the .bin and drilled down to the appropriate .exe and ran that.  It gave me a colorful, hierarchical indication of running processes.

I decided to put it to a test.  I ran GoodSync and did a Ctrl-F in Process Hacker.  That gave me a separate list of files, processes, and threads that apparently involved GoodSync.  But where was GoodSync within the pretty list of colored processes, there in the main Process Hacker window?  I clicked on the Description heading, and that gave me an alphabetical list.  Ah, there it was.  GoodSync was currently using up to 3%, no, 5%, no, make that 10% of CPU resources.  The number kept rising.  In the amount of time it took me to write these words, it was up to 25%.  I had a quad core processor; maybe 25% was going to be the limit.  I clicked to sort on the CPU heading.  At first, GoodSync was solidly in second place as the greatest consumer of CPU resources, behind System Idle Processes.  It seemed that the latter just meant that I had a lot of idle capacity.  That seemed to be the message from Moo0 too:  the CPU was not very busy.

Process Hacker also said that GoodSync was using a steady 468MB in Private Bytes.  A StackOverflow post said that private bytes was "the current size, in bytes, of memory that this process has allocated that cannot be shared with other processes."  Another post in that thread clarified:  this value included pagefile (i.e., virtual) memory.  So it didn't necessarily mean that GoodSync was using almost a half-gig of what the RAM chips in my computer could offer.  The thread seemed to say that the most important value of that number was in whether it was growing, which would indicate a memory leak -- which apparently meant that the program in question kept asking for more and more memory, without reusing or returning what it had already requested and was no longer using.  This didn't seem to be a problem:  the Private Bytes number for GoodSync had not yet risen beyond about 480MB.

I clicked on the I/O Total Rate heading in Process Hacker.  It put GoodSync by far at the top of the list, using 22 mB/s (with variations), when the next most disk-intensive programs were generally asking for less than 20 kB/s.  This concurred with Moo0 -- it was tending to show GoodSync as the chief loader of the hard drive -- but this was giving me much more information about how GoodSync compared to the other programs running.  (I was working in the Processes tab in Process Hacker.  There were also Services and Network tabs.)  I also noticed, by this point, that the Private Bytes number did seem to be creeping upwards, now reaching 520MB.  I wondered where it would be in an hour or two.

So now, could I put the brakes on GoodSync?  I right-clicked on it, there in Process Hacker, and saw at least three relevant options:  Terminate, Suspend, and Priority.  Of these, the only one that would put on the brakes without completely ending progress was Priority.  That one was familiar; I had seen the same options elsewhere, probably in Task Manager.  The options were Real Time, High, Above Normal, Normal, Below Normal, and Idle.  Normal was the default.  I had seen somewhere that Normal was the default for everything in Windows.

So, sad to say, this thing wasn't going to give me fine-tuned tweaking options, like "40% of Normal" or "Run only when computer is idle" or "Try to finish this process by tomorrow morning."  I realized that not all of these possibilities might be feasible in Windows 7.  And, wow, what about RAM?  GoodSync was up to 905MB of Private Bytes now.  For that matter, Internet Explorer (where I was writing this) was at 870MB (with eight tabs open, and after 50 hours of uptime, according to Moo0).  I was using RizoneSoft MemoryBooster to keep RAM available, but it didn't have options to put restrictions on individual programs, and hitting its Optimize Memory button at this point didn't have any effect upon the Private Bytes reported by Process Hacker for GoodSync and IE.  I guessed that the situation was that memory leaks couldn't be squeezed much -- that you might basically have a choice between letting the program run or shutting it down so that memory could clear.

I dimly recalled that GoodSync might have its own internal option to throttle itself.  A look at this point reminded me:  its Auto > General tab would allow a specific sync job to slow down file copying if the average download speed exceeded a certain value.  I wasn't quite sure how that would work, but I didn't think the problem was with the speed of downloads (i.e., how quickly they would travel across the ethernet cable between computers).  What seemed most demanding about GoodSync was its use of system resources to do its calculations of what needed to be copied.  In other words, I didn't care whether it was slowing me down because of calculations, or downloads, or for some other reason; I just cared that, overall, it was slowing me down.  And at this point I was not seeing anything specifically geared toward that.  And even if I had, I'd still have a similar concern for some other programs.

Further exploration in Process Hacker indicated that I had overlooked another possible location of options.  I right-clicked on the Process Hacker line for GoodSync and chose Miscellanous.  There, I saw at least three intriguing options:  I/O Priority, Page Priority, and Reduce Working Set.  I decided to see what would happen if I changed a bunch of settings to their minimum values.  So I changed GoodSync right-click Priority from Normal to Below Normal.  I didn't see any difference, there, between Below Normal and Real Time (the highest setting).  On, then, to Miscellaneous > I/O Priority.  It was set to Normal; I set it to Very Low.  Still no obvious difference in the demands on CPU, I/O, or Private Bytes shown in Process Hacker.  Next, Miscellaneous > Page Priority.  It was at 5 (the highest possible value); I set it to 1.  Finally, Miscellaneous > Reduce Working Set.  It was just an on-or-off option.  I turned it on.  No visible difference in the numbers.  I decided to turn off Reduce Working Set, putting it back to its default setting, since I didn't know what it was.  Seems I was wrong:  it wasn't a checked, toggling option; evidently I was just reducing the working set further (whatever that meant) every time I hit it.

Well, by this point, as a correction to my impression from a moment earlier, it seemed that something had changed after all.  (It helped to see this when I changed Process Handler > View > Update Interval to a slower setting.)  Maybe this change was due to my adjustments to the settings, or maybe GoodSync had finished something it was working on, but for whatever reason it had dropped from an I/O Total Rate of 20+ mB/s to more like 3 mB/s.  I suspected that I had now given myself the equivalent of an option to "Run only when computer is idle."  With all these priorities set so low, hopefully the computer would suppress GoodSync when I had other things to do.  The risk now was, no doubt, that GoodSync would never finish its tasks.  I would have to just let it run a while and see how that went.

After closing Process Hacker and letting a few days pass (along with a reboot or two), I returned to see what was happening with GoodSync.  The system had now been up for a little over two days, and at this moment the spinning system tray icon showed that GoodSync was actively at work.  PH showed GoodSync as having 1.14GB in Private Bytes allocated to it.  Its I/O Total Rate was not exceeding about 1.5 mB/s.  It looked like my settings had persisted.  I was not actively using that machine at that point, so I couldn't say whether there would still be noticeable slowdowns.  But it seemed unlikely.  Moo0 was reporting that the CPU, RAM, and hard drives were almost never fully burdened.  And yet GoodSync did seem to be getting its tasks done.

I was not quite sure whether Process Hacker right-click settings all applied only to the specific process that I had clicked on.  Some appeared to apply to all, or at least multiple, processes.  There was more to learn.  But at least it did appear that Process Hacker had enabled me to slow down a program that was grabbing too much of system resources, without noticeably impairing that program's functioning.

Windows 7: Setting and Maintaining Accurate System Time

I wanted to keep two computers' clocks set the same, for purposes of synchronization, so that they would have an accurate sense of whether the version of File X on computer A was newer than the version of File X on computer B.  I had previously installed (or, more accurately, just added a copy of) Judah Levine's portable NISTIME 32 in something of a rush, when installing Windows 7, and, later, had vaguely recognized that it was not working right and/or I had not set it right.  Now I decided to work out the kinks in this function.

NISTIME-32BIT.EXE

I started with the National Institute of Standards and Technology (NIST), from which programs like NISTIME 32 would draw the current time.  It developed that NIST had a program called nistime-32bit.exe.  It turned out to be the same as NISTIME 32, just slightly updated.  The webpage's instructions were to start by going into File > Select Server and then Query Server > Now.  Somewhere I saw advice to choose a server near me.  I was tempted to choose two different ones, one for each computer, so as to have accurate time in case there was some terrible disruption of the national timekeeping system.  Then I realized that this could have the effect of making rivers run upstream, where my files were concerned, to wit:  new could be replaced by old.  Being up-to-date on the latest developments in American chronology suddenly seemed less important than making sure I didn't accidentally overwrite today's crossword puzzle.

When I went to the Query Server > Now menu pick, I got a dialog indicating that NISTIME 32 was prepared to adjust my computer by 0.953 seconds.  I told it to go ahead.  I also went into Query Server > Periodically and told it to update the computer every 12 hours.  Query Server > Server Status confirmed these settings.  File > Help in Choosing Dirs told me to hit File > Save Config to save my settings.  This gave me "File Error:  Cannot open file to save configuration."  That problem may have been caused by nesting the program too deeply in a subfolder.  I moved it elsewhere and tried again. Now it seemed to confirm that it had saved my settings, and it created NISTIMEW.CFG in the same folder as the program's portable executable (nistime-32bit.exe).  I exited and restarted, and it remembered what I had told it.  But I had to remember to hit File > Save Config; it would not remember anything.

But then, when I did go into Query Server > Periodically, specified 12 hours, and hit File > Save Config and then File > Exit, I could not get it back.  The program refused to become visible.  I tried a couple of times, and then looked at Windows Task Manager (Start > Run > taskmgr.exe) > Processes tab.  Taskmgr showed four separate instances of "nistime-32bit.exe *32."  I selected them and clicked End Process, one by one, and then ran nistime-32bit.exe again.  It returned to taskmgr.exe, but not to the screen.  I minimized all windows, one by one, but, no, it was not lurking anywhere.  There didn't seem to be a taskbar or system tray icon for it.  It was here, and yet not here.  I killed the processes again, now that I had started one or two new ones.  I renamed NISTIMEW.CFG to be something else, and now it would start, and it saved new settings in a new NISTIMEW.CFG.  Apparently the config file had gotten corrupted.  I had originally created that file manually in lowercase (nistimew.cfg); possibly something about the program needed the uppercase filename.

But now, same thing again.  Exiting and restarting gave me a hidden program:  visible in Task Manager's Processes tab, but not visible onscreen.  When I right-clicked on nistime-32bit.exe *32 in Task Manager and selected Properties, I got an error:  "Windows cannot find [pathname] nistime-32bit.exe."  I ended the process again.  I created a shortcut to the .exe and tried starting it that way.  I had no reason to think that would make any difference, and in fact it didn't.  I tried moving all of the files from the folder where I had put nistime-32bit.exe, and placed them all instead in C:\Windows, with a shortcut to the executable in my Start Menu.  That wasn't the answer; I still got lurking program sessions that appeared in Task Manager but nowhere else.  I deleted the CFG again and tried again.  Now it ran.  I went directly to File > Save Config without making any changes.  It indicated that it had saved the config file.  I exited and restarted the program.  It ran.

Now I saw something that may have explained the config file problem.  The server list had changed.  The Colorado server that I had selected previously was no longer listed in File > Select Server.  I had previously gone into File > Update Server List, and that had generated a message:  "New server file is C:\Windows\NIST-SRV.LST."  It did that again now, when I designated a new server.  I hit File > Save Config and then File > Exit, and then restarted the program.  Now it was running normally.  I moved the three files (the exe, cfg, and nist-srv.lst files) from C:\Windows back to the folder where I really preferred to have them.  It seemed that the server list had not properly updated when the files were in that folder originally.  I restarted and went through the same steps -- update server list, choose a new server, save config -- and now I was exiting and restarting without a problem.

But no, I spoke too soon.  When I restarted, saved a 12-hour periodic refresh, and exited, it would not restart.  Deleting the config and moving the other files back to C:\Windows did not fix it.  The problem seemed to relate specifically to the attempt to set up recurrent time checks.  I was doing something wrong, or perhaps the program had a bug, or maybe it was not suited for 64-bit Win7.  I went to the NIST webpage cited in the program's Help > More Help and sent an email to the Webmaster link at the bottom of that page, pointing them here.

The Built-In Windows Time Sync Option

I decided to look for an alternative time-updating program.  I ran a search and discovered that there was apparently some kind of automatic time-updating arrangement built into Windows.  The advice there was, however, that "The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs."  That was consistent with the fact that my two computers' timeclocks tended to be somewhat inconsistent with one another.  I had not tried to see how inconsistent they could be, or how long they could remain that way.  I did see an indication somewhere that Windows defaulted to a weekly time update, so maybe it would verify that it was accurate to within a minute, or something, every week or so.

That appeared to be steered by Control Panel > Date and Time.  That dialog could also be opened by right-clicking the clock in the system tray and choosing Adjust Date/Time.  Or, as I now learned from Eric Phelps, it could also run from the command line via "rundll32.exe shell32.dll,Control_RunDLL timedate.cpl."  The latter option would facilitate the option of opening the Date and Time dialog for manual adjustment via, say, a batch file that would open it automatically (to the correct tab) every day, week, or whatever.  (Later, I found a How-To Geek webpage that said I could just run "w32tm /resync" as administrator to resynchronize the clock without even going into the Date and Time dialog.  That, too, could be incorporated into a scheduled batch file.)

The Date and Time dialog > Internet Time tab > Change Settings option gave me a choice of synchronizing with time.nist.gov, which I understood to be the most accurate (though others in that list, not counting time.windows.com, appeared to be cousins of NIST).  I noticed that the dialog told me, here, that "This computer is set to automatically synchronize on a scheduled basis."  The previous sync site, as I saw on the other computer, was time.windows.com."  I wasn't sure how synchronizing with that site could have left my two computers with different times -- differing by seconds, that is, not by minutes -- unless maybe time.windows.com was just not that worried about the seconds.  Or maybe it was trying to synchronize when my router was doing its daily self-restart, and was therefore not getting access to the online clock?  I wasn't sure.  (Note:  Fouzan said that this whole process wouldn't work if the computer was on a domain.)

Curious about the timing, I went into Start > Run > taskschd.msc > Task Scheduler Library.  There were maybe 15 items in the list, and none of them were obvious time sync tasks.  So another possibility was that some bug or tweak, brought into my system somewhere along the line, was preventing the creation or execution of the scheduling function.  Another emerging possibility was that, as stated in a How-To Geek webpage, time.windows.com (which my systems had been using by default) had "a ton of problems with uptime."  So possibly I had already fixed my problem, just by switching the machines to use time.nist.gov in the Date and Time dialog.  (I did notice, as soon as I made that switch and clicked the update button, that both computers' clocks showed exactly the same time.)

Other Possibilities

I ran another search and found a Gizmo recommendation for Dimension 4 as a time correction utility.  It occurred to me, at this point, that possibly I had fixed my problem, just by switching away from time.windows.com (above), and that maybe I should just let things slide for a week or two.  I decided mostly just to record some notes, here, for possible future reference.  So instead of installing Dimension 4, I just dragged the icon for its webpage from my browser's Address bar over to the Time subfolder in my customized Start Menu.  If I ever needed it, I could follow the link at that time.

There also appeared to be more to know than I had realized, regarding Task Scheduler (taskschd.msc).  In Task Scheduler's left-hand pane, I went down the tree into Task Scheduler Library > Microsoft > Windows > Time Synchronization.  Now I saw that my machine was indeed set to synchronize time at 1 AM every Sunday.  I saw advice from Tina Sieber on a way to adjust and improve the scheduling via Task Scheduler.  Tina seemed to believe, however, that using a separate program might be the simpler and more accurate approach.  Tina pointed toward two other programs, Atomic Clock Sync and AtomTime.  The webpage for the latter seemed very old.  I was not sure how it would fare in a 64-bit Windows 7 world.

For now, the solution seemed to be simply to go into the system's clock and change its time source to NIST.  My monthly batch file brought up the NIST/USNO timepage on the first of every month, so I could observe, later, whether my two computers were again diverging from one another and/or from the time on that webpage.  If they didn't stay in line, I would have two options.  One would be to add one of the foregoing command lines to my daily or weekly batch files, to permit manual and/or automatic checking and/or resynchronization.  Another would be to try one of the several freeware utilities just mentioned, particularly Dimension 4 or Atomic Clock Sync.