Tuesday, April 17, 2012

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: Shift and Control (not Caps Lock) Key Stuck On - Slow Keyboard Response

I had a problem, in Windows 7, that apparently afflicted Windows XP users as far back as 2005.  For some reason, on a system that did not previously have this problem, I would be typing along and suddenly thE DAMN THING WOuld start and then maybe stop typing in all caps, like that.  A search indicated that a fair number of people were having this problem.

There was the usual assortment of suggested solutions.  One was hardware, notably the keyboard.  I had replaced keyboards and found that didn't solve the problem for me -- not to mention that I was having the same problem, arising at about the same time, on two different computers.  Some observed that rebooting would fix the problem, at least temporarily.  If that was working for me, I would have to emphasize the "temporarily" part.  Some noted that Control Panel > Ease of Access Center > Make the Keyboard Easier to Use might be set to turn on Sticky Keys.

These were not solutions fo rme.  I did a virus scan and found no problem.  It seemed that some rogue program may have screwed things up.  I might eventually figure out which one.  If not, one solution would be to roll back to an earlier System Restore.  But System Restore was not functioning well; I had only a few recent restore points, not predating the problem.  I could do an image restore from some weeks earlier, but I was hoping for something less drastic.

There were some other, funkier suggestions.  One involved a sort of phantom limb theory, like when a person has a bad itch on his/her right arm but cannot scratch it because the arm has been amputated.  The concept here seemed to be that Caps Lock was on when an external or alternate keyboard was removed, so now the computer was still feeling the pain of that setting, and the solution was to plug in that other keyboard and turn off the Caps Lock.  That seemed possible; I had recently plugged in a USB keyboard because my PS/2 keyboard was not responding during a reboot with a certain kind of boot disk.  But trying again with the USB keyboard, with or without the PS/2 keyboard, after reboots, did not seem to fix the problem.

Two other suggestions offered simple solutions.  One suggestion was just to use the other shift key once.  That is, I always used the left-side Shift key, so now I used the right-shift key one time.  The other suggestion was to bring up the On-Screen Keyboard and click once on each of its two Shift keys.  Together, these two suggestions seemed to say that the solution was to use each Shift key on a keyboard, whether physical or onscreen.  (The onscreen keyboard was at Control Panel > Ease of Access Center > Use the Computer without a Mouse or keyboard.)  I found that the physical keyboard solution seemed to work, but only temporarily.

As this problem went on, I learned more about it. It wasn't only the Shift key. It was also the Control key. It seemed to be a problem of slowness. The computer was processing Shift and Control keypresses belatedly. For instance, I would select several files in Windows Explorer, using the Control Key; and then, when I would try to select another one, if I didn't allow time for the system to process the Control keypress, clicking on an additional item would deselect all the others.

A search led to the suggestion that I should see if I had the same problem when using the onscreen keyboard. This seemed impractical, since (as I confirmed in a brief trial) I would not have the same feel through the Onscreen Keyboard (Start > Run > osk.exe). It was also suggested that I see whether the situation persisted in Safe Mode. If there was no problem in Safe Mode, then the prescription would be to perform a clean boot.

It seemed the problem might be due to my KVM (keyboard-video-mouse) switch.  That is, I had one keyboard for two computers.  I switched back and forth by using a hotkey.  It was an IOGear PS/2 KVM.  Right around this time, I did variations on having the KVM connected to only one computer.  My notes are imperfect, but it seemed that this may have made a difference.  I did replace the KVM around that time as well because it was defective, so maybe this stemmed from that.

I also reinstalled Windows 7 around this time.  Maybe that was part of the solution too.  Not sure.

Windows 7: Missing System Restore Points

I was using Windows 7 with System Restore (Start > Run > SystemPropertiesProtection.exe) turned on for drive C only.  It was set to allocate 16GB of the drive to store System Restore points.  Yet it was storing only two such points.  Clicking "Show more restore points" did not increase the number. 

By way of background, I was not running a dual-boot system and had been making daily backups.  Recently, I had been making those backups manually by running "start "" SystemPropertiesProtection.exe" in a daily batch file, so that I could watch the situation.  (The purpose of the empty internal quotes ("") was to provide a null argument.  It probably wasn't necessary in this case; it seemed to be helpful sometimes.)  Previously, I had been using a VBS script triggered by a Task Scheduler entry.  I had also not rebooted recently.  According to Moo0, at this particular time my system had been up for nearly three days, but my only restore points were from within approximately the past 24 hours.

This problem seemed to have many possible causes.  Glancing through a list of potential fixes provided on a website oriented toward Windows XP, I saw a reference to Event Viewer (Start > Run > eventvwr.msc).  I was not very familiar with that, so I ran a search and found a suggestion to focus on VSS entries.  VSS stood for Volume Shadow Copy or Volume Snapshot Service.  The basic idea was that VSS would allow Windows to make a copy of a file even if that file was in use, which would be the situation for some Windows 7 system files while the system was running.  Apparently System Restore used VSS.  The suggestion was, in other words, to see what Event Viewer would say about VSS-related problems.  To do that, I went into Event Viewer > Filter Current Log > Event Sources > VSS > OK.  This gave me a list of items.  (Later -- see below -- I saw that I had taken incomplete notes here.)  I clicked on the Date and Time column heading to get the most recent ones.  These were all Information-level notices.  They were all the same:  "The VSS service is shutting down due to idle timeout."  This did not seem relevant to my problem.  VSS was running.  I was getting System Restore points.  They were just being deleted prematurely for some reason.

Another suggestion was to check Services (Start > Run > services.msc) to verify these settings:  Volume Shadow Copy = manual or automatic; Task Scheduler = automatic; Windows Backup = manual or automatic.  Again, these suggestions seemed irrelevant, since the restore points were being made.  In any case, they were set correctly on my system.  Along with those suggestions, though, was a worthier one:  go back into Event Viewer and look for System Restore entries with Event ID numbers 8194, 8195, 8196, or 8198.  Of these, the ones that seemed most likely to be relevant were 8195 (System Restore Deactivated) and 8198 (Restore Point Deleted).  A search focusing on 8198 did not turn up anything immediately obvious, so I shelved it for the moment.  In Event Viewer, I sorted by clicking on the Event ID column.  It took a while to sort.  It showed no errors anywhere near 8194 to 8198.

A seemingly related suggestion was to run Task Scheduler (Start > Run > taskschd.msc) > Task Scheduler Library (left pane) > Microsoft > Windows > System Restore > select an item in the top pane > History tab (middle pane).  There didn't seem to be a relevant item in the top pane, but I just clicked on something.  I saw that the History tab said "History (disabled)."  A search yielded the suggestion that I go into Task Scheduler's right pane > Enable All Tasks History.

One obvious suggestion was to make sure I had ample space on my drive for the System Restore points.  In Windows Explorer > right-click > Properties > General tab, drive C showed only 2.1GB free on an 80GB partition.  I was not sure whether that included what I had already allocated for System Restore points.  To figure this out, I wanted to see the size of the System Volume Information folder, which was where Windows 7 stored those points.  In Windows Explorer > right-click > Properties, System Volume Information was shown as having size zero.  To change that, I followed the suggestion to go into Properties > Security tab > Edit > Add > Administrators > Check Names > OK > Full Control > OK.  This gave me an error:

Error Applying Security

An error occurred while applying security information to:

C:\System Volume Information\WindowsImageBackup

Acesss is denied.
I got recurring messages like that.  At some point, I clicked Cancel.  I got a warning that I should Continue to avoid inconsistencies, but there was no option to Continue.  The box was now showing Full Control despite the error message.  It now reported that the System Volume Information folder had a size of 6.45 GB.  That roughly agreed with System Restore, which was reporting that my Current Usage was 6.10 GB.  I had made one or two more restore points; System Restore said I now had four.  I reduced the size allocated to System Restore from 16GB to 12GB and took another look at the Properties for drive C.  It still reported 2.1GB free.  So apparently the space allocated for System Restore was not marked as unavailable until it was actually used; the allocation was just a ceiling for System Restore, telling it when to start jettisoning old restore points.  As long as I remembered to exclude the System Volume Information folder from drive image backups (so as to prevent those backups from being unnecessarily inflated), there did not seem to be any particular drawback to allocating large amounts of space, just in case I would want to have access to historical backup points.  As a side note, it occurred to me that it might be possible to archive such points.  I could have experimented with making a ZIP copy of the contents of System Volume Information, to see if System Restore would work from a restored ZIP.

The next day, now that I had enlarged drive C, it showed plenty of space.  System Volume Information was back to showing zero bytes, so I repeated the steps above.  This time I went all the way through, clicking Continue until it stopped asking.  It only asked a half-dozen times.  Properties was still showing only about 6.6 GB allocated.  I still had only those restore points that had been made in the last 24 hours.  Disk space was not the issue.

It seemed that I must have overlooked something in Event Viewer.  I couldn't tell, from these notes, which part of Event Viewer I had examined the previous day.  Evidently I had selected something in the left pane in order to get the Filter Current Log option.  Maybe I had selected the wrong thing.  I saw, now, that the original suggestion was to click Windows Logs > Application in the left pane.  Filtering there for VSS still produced no errors numbered around 8194 to 8198.  Instead of filtering for VSS, I went to the top of the list and clicked "All Event Sources."  That produced nothing -- maybe it was still calculating -- so I changed the top line, "Logged," to "Last 7 days."  Sorting by the Event ID column, I saw an 8193 item (created restore point) but no indications that any restore points had been deleted.

I had rebooted in order to change the size of the partition.  Maybe restore points were being deleted during reboots?  I didn't plan to reboot during the next day or more, so I decided to let it sit another day and then take another look.  This time, I had the same restore points, now going back two days, plus some new ones.

Over the next several days, my restore points accumulated.  Apparently I had fixed something.  Rebooting may or may not have been removing them previously; if so, that was no longer happening.  At the time when I was writing these words, the system had been up for only about one day, but the available restore points stretched back almost a week.

So now I had an opportunity to distill a lesson from these remarks, because my secondary computer was doing the same thing.  It was keeping restore points going back only a day or two.  So what had I done to fix the problem?  I wasn't sure.  I went back through some of the foregoing steps.  First, I closed System Restore.  I went into System Volume Information > right-click > Properties > Security tab > Edit > Add > Administrators > Check Names > OK > Full Control > OK.  I clicked Continue through a half-dozen error messages.  I went back into System Restore (i.e., Start > Run > SystemPropertiesProtection.exe > select drive C > Configure > reserve 10GB > OK.  It was 6GB before; it was possible (but seemed unlikely) that that was the problem.

I let it go for a few days.  The problem was solved.  I was now getting restore points going back several days and surviving reboots.

Sunday, April 8, 2012

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:
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                      *
*                                                                             *

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.

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

Debugging Details:
LAST_CONTROL_TRANSFER:  from fffff880015e322f to fffff8000307ed40
[displaying, here, only the right end of each line - RW]

fffff880`053b9eb9 c744244053eeffff mov     dword ptr [rsp+40h],0FFFFEE53h
SYMBOL_NAME:  dxgmms1!VidSchiVerifyDriverReportedFenceId+ad
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: dxgmms1
IMAGE_NAME:  dxgmms1.sys
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.

Monday, April 2, 2012

Windows 7: Eliminating "This Folder Is Shared With Other People" Message

I had installed Windows 7.  Now, when I would try to move or delete some folders, I would get this message:

This folder is shared with other people.

If you move this folder, it will no longer be shared.
That message was correct:  I had, in fact, shared the parent folder (and all of its subfolders, including this one) with my other computer.  And I wanted existing and newly created subfolders to continue to be shared.  I just didn't want to receive this warning.

I tried the approach of going into Control Panel > HomeGroup > Leave the homegroup, because someone advised that this was the solution.  It wasn't.  I tried a search.  This led to a thread with some heartwarming rants about what a dumbass feature this was.  That thread also contained the suggestion that, at least for purposes of deleting (as distinct from moving) folders, a workaround was to cut and paste files and folders into Recycle Bin, rather than trying to delete them directly.  There was also a command line alternative that supposedly worked for wiping out lots of subfolders:
for /D %d in (*) do rmdir /S /Q "%d"
My guess was that the command line would also work for moving, in a pinch:  type MOVE /? for guidance.  But I didn't want a command-line solution.  The thread also offered a couple of other complicated workarounds with potential side effects.  Before going that route, I tried the suggestion to take ownership of the folder in question.  I had already added a Take Ownership context menu (i.e., right-click) option in Windows Explorer, so I used that now.  I used it at the level of the entire partition.  That didn't solve the problem.  I tried it again on the top-level folder.  That didn't do it either.  I verified that I had already given Full Control to Everyone in the Sharing context menu option, so that wasn't the solution either.

Another thread contained messages repeating the view that, as a deliberate feature of Windows, this couldn't be changed.  I took a look in TweakNow PowerPack 2012, in case they had a fix.  I hadn't really used TweakNow previously, but now I saw it wasn't really a tweaker in the sense that Ultimate Windows Tweaker (UWT) was.  So I ran UWT instead.  But no, UWT didn't seem to have a solution either.  So far, the only solution I had seen was that some people had repartitioned their drive and reinstalled Windows from scratch.  But that was a pretty draconian solution, and it didn't seem to guarantee against a recurrence of the problem.

Back in Windows Explorer, I right-clicked on the drive being shared and selected Properties > Security tab > Edit > Add > Everyone > Check Names > OK > Allow Full Control > OK.  That took a while, as it went through the drive, with a message that said, "Setting security information" various files and folders.  This was obviously not a very secure solution.  Nor was it logically related to sharing.  It was just a guess.

In another thread, someone said that they noticed this behavior began when they installed RC-1 (i.e., Windows 7, First Release Candidate).  As noted above, people had been saying it was a built-in Windows feature.  But there was at least the possibility that some program had triggered it.  In that spirit, someone else in that same thread offered the belief that it might be related to Windows Mail.  That was a possibility.  I had installed Windows Live Mail.  I didn't like it much -- it was very slow to start.  But I had already uninstalled it.  There didn't seem to be much more I could do on that front.  I tried running Glary Registry Cleaner, just in case that would make a difference.  It identified a lot of problems, but did not fix this particular one.  In another thread, someone suggested that the culprit might be the network sharing service in Media Player 11.

I saw recurrent references to the C:\Users\[username]\Appdata\Local\Temp\WPDNSE folder.  For username Ray, mine had nothing in it.  Evidently they came to that folder because its name was appearing in an error message.  I wasn't getting that.  The general idea seemed to be that one user might somehow be linked to another user at that folder.  That was interesting.  I looked into the possibility that this "shared folder" problem might be due to the existence of an unnecessary user account.  As described in another post, I pruned out some extraneous user accounts.  But that did not resolve this problem.

Over time, the problem appeared less frequently.  It seemed that there might have been an ownership or sharing event, occurring at one time, that became less relevant as my folders went through various processes of being renamed, moved, reshared, and so forth.  One post gave me the idea that the problem might be in Windows Explorer > select a folder > right-click > Properties > Sharing tab > Advanced Sharing > Permissions.  At this moment, the only group or user listed there was Everyone.  It seemed that, previously, there might have been additional entries there, for Ray, Administrators, and/or System.  The post made me think that, even though all roads seemed like they should lead to Mecca, the mere presence of multiple people here would confuse Windows.  Maybe the original warning that "This folder is shared with other people" was Windows' way of telling me that it was going to remove the others and leave only Everyone on the list.  I didn't test this; this was just an idea from that post.  At the time when I decided to close this post, it's not so much that the problem had disappeared as that it had become more rare.

Sunday, April 1, 2012

Windows 7: Deleting Excess "User" Accounts

One day, while wandering through the forest of drive C, I came upon C:\Users, where I beheld more users than I had anticipated. We had Administrator, All Users, Default, Default User, Public, Ray, and Ray Woodcock.  Who were all these people?  And did I want to be associated with them?

Most of these weren't listed in Control Panel > User Accounts > Manage another account.  There, I saw only Ray and Guest.  (I had set myself to be Administrator.)  Guest wasn't listed in C:\Users, so there seemed to be some slippage here. Maybe Guest didn't actually exist yet; the button was there just so I could add a guest account when needed.  So were all these Users in C:\Users real?  Could I delete any of them?

This appeared not to be exactly the same as deleting an account that would appear in User Accounts.  Here in C:\Users, I was dealing with folders that looked like they were tied in with other things.  In other words, it seemed that it could be a bad idea to delete the wrong account.  I ran a search, seeking guidance, but even Microsoft seemed pretty blasé about the prospect:  "If you have a user account on your computer that is not being used, you can permanently remove it by deleting it."  Period.  Just do it.  There were different steps, they said, according to whether the computer was on a workgroup or a domain.  Their procedure for making that determination was (in my translation) to go to Start > Run > SystemPropertiesAdvanced.exe > Computer Name tab.  (Soon, I would run into stories of grief from those who had actually proceeded to wipe out their C:\Users subfolders willy-nilly.)

Back in C:\Users, I went into the Administrator folder.  The only thing there was a subfolder called Application Data\ImgBurn\Log Files.  Well.  Could I set ImgBurn to put its log files somewhere else?  It seemed I could.  The relevant settings were in ImgBurn > Tools > Settings > File Locations tab.  There were actually four different folders that I needed to create elsewhere, in order to completely eliminate ImgBurn's need for C:\Users\Administrator.  I saved the ImgBurn Settings.ini file so that I wouldn't have to do this again after some future installation.  Then I deleted that folder.

Next, I went into C:\Users\Ray Woodcock.  This one had evidently been created by Microsoft Office, for the use of Outlook.  But I wasn't using Outlook.  So I just deleted C:\Users\Ray Woodcock.

The list was getting shorter, but now the sledding was tougher.  I wasn't going to delete the Ray account.  Two of the four others -- All Users and Default User -- had padlock icons, suggesting that Windows would rather keep them.  All four also had lots of subfolders.  It appeared they might not meet the Microsoft qualification:  IF the account is not being used.  These accounts were not being used by me, directly.  But it appeared that someone was using them.

I tried a search for the Public account.  I ran pretty quickly into advice not to delete that folder, and a cry for help from someone who had done so.  End of story on that.

Well, how about the (padlocked) All Users folder?  For that, a search yielded the information that C:\Users\All Users was just a symbolic link to C:\ProgramData.  I attempted to check this.  Yes, both folders did seem to contain the same subfolders, apparently used by a variety of programs:  Adobe, Apple, Skype, etc.  The status bar at the bottom of Windows Explorer said there were 26 items in each.  It seemed that the All Users folder was there for backward compatibility with programs that would look for it instead of for C:\ProgramData.  In short, I could make things difficult by deleting it, and it seemed that deleting it wouldn't actually have anything to do with any real accounts.

This left me with the Default and Default User folders in C:\Users.  I didn't understand the difference between these two, so I ran a search.  MrBruce1959 said that Default was a system folder, not to be toyed with, whereas Default User was supposed to be the initial or default account for the person who would be using the computer.  In that case, I didn't understand why Windows created a separate Ray account (my choice of name, their choice of folder) instead of renaming Default User to be Ray when I was first setting up the system.  Why leave a superfluous Default User folder after the real default user has made an appearance? 

I tried a different searchSomeone passed along the rumor that I could just go ahead and delete the Default User folder.  Another post spoke blithely of deleting the Default User folder (actually, they said "profile," not folder) with a script, so as to replace it with a preconfigured Default User replacement.  That one was followed (at the bottom of the Experts Exchange page) with an extended discussion of programming technique, so apparently it was OK in principle to delete the folder, at least if a look-alike then took its place.  A post in another thread said that Default User was the one from which other user profiles were built.  I didn't plan on letting anyone else into my world, so I felt I could do without it for that purpose.

I decided to zip the Default User folder, delete it, and save the ZIP for future reference.  Before doing this, I made a System Restore backup (Start > Run > SystemPropertiesProtection.exe).  Also, since System Restore had been flaky sometimes in the past, I made an Acronis drive image.  I gave this some time, to see whether it would have adverse effects.  A couple of days later, the system seemed to be running OK.  The removal of the Default User folder did not seem to have any immediate or obvious negative effects.