Documenting Computer Work with Screenshots and Duplicate Detectors

I was doing some work in Windows 7.  I wanted to log the changes periodically as I went along.  I had already developed a batch file, which I called Shotshooter.bat, to take screenshots and save them as .png files periodically.  (I think this will work in all versions of Windows.)

Having already done the NirCmd setup required to make that batch file work, I slightly revised it to read as follows.  (If the print is too small, use Ctrl-+ or copy and paste into Notepad.  Batch files are best not edited in a word processor like Word, since they change characters sometimes.)

:: Shotshooter.bat

:: Captures a series of screenshots.

:: See http://www.nirsoft.net/utils/nircmd.html for info on NirCmd.exe.

:: Takes two arguments:  how many shots, and how many milliseconds between shots.

:: Sample usage:  shotshooter 3600 1000
:: That example would take screenshots every second for an hour,
::   assuming the computer could work that fast.

:: To kill the program sooner, use Task Manager (Ctrl-Alt-Del) > Processses > nircmd.exe.
:: IrfanView provides a fast way to play back results.

:: Create Screenshots folder on drive D

D:
md \Screenshots
:: Go to the drive and folder where you put NirCmd.exe

W:

cd "\Start Menu\Programs\Tools\Programming and Scripting\NirCmd"
:: Run NirCmd with the desired settings

nircmd.exe loop %1 %2 savescreenshot D:\Screenshots\scr~$currdate.yyyy-MM-dd$-~$currtime.HH_mm_ss$.png

:: Go see what you've created in D:\Screenshots

start explorer.exe /e,"D:\Personal Projects\View These Weekly"

Having created Shotshooter.bat, now I wanted to run it.  I had already used Ultimate Windows Tweaker (UWT) to install a right-click option to open a command window in any folder I would select in Windows Explorer, so all I had to do was open a CMD window where I had saved Shotshooter.bat, and just type "shotshooter 1200 30000" and hit Enter.

(If I hadn't installed that option with UWT, I could also have gone to Start > Run > cmd and then navigated manually to the proper folder with change-drive (e.g., D:) and change-folder (e.g., cd "folder name") commands like those used in Shotshooter.bat, above.  Note that quotation marks are necessary if folder names contain spaces or possibly if they are too long.)

Those parameters of 1200 and 30000 meant that Shotshooter.bat would use NirCmd to take a screenshot every 30000 milliseconds (i.e., every 30 seconds), and would take a total of 1200 screenshots (i.e., would run for 10 hours).  It would save them in D:\Screenshots, and now I would have to decide what to do with them.

When I was writing up these notes, I didn't recall whether NirCmd could also produce JPGs or other image formats.  It probably could.  But after getting used to IrfanView, it probably would have been easier to just use IrfanView (File > Batch Conversion/Rename) to do a mass conversion of PNGs into JPGs if necessary.

The problem with a straightforward slideshow was that, if I allowed a few seconds for each screenshot, I could easily wind up with an hourlong show that would feature extended periods of no change.  On this particular day, I had gone to the store and out to lunch, so presumably nothing was happening during those periods.  The changes that I would want to see might pop up for only a few seconds in that hourlong show.

It seemed I had better get rid of the PNGs that merely repeated the same unchanging screenshot for long periods of time.  To do this, I tried a couple of approaches.  After making a backup of my Screenshots folder, I started with Awesome Duplicate Photo Finder (ADPF).  I adjusted its settings to examine PNGs and told it to search only the D:\Screenshots folder.  It felt that, out of my 1,200 screenshots, 1,160 were potential duplicates.  Closer examination revealed that, while many of those files were not what ADPF considered 100% identical, hundreds were.  Unfortunately, ADPF did not offer a way to bulk-delete the 100% matches.  I did not take the time-consuming approach of just letting ADPF guide me through the 580 pairs of images comprising those 1,160 alleged duplicates, making manual choices as to whether I should delete one of the two images it showed me.

I tried another approach.  Among the many free duplicate file finders, I had long used DoubleKiller.  (Exact Duplicate Finder gave the same results as one type of DoubleKiller comparison, but offered fewer comparison options.)  For some reason, a CRC and size comparison in DoubleKiller gave me only 161 duplicates.  I suspected DoubleKiller was being too precise.  Doing an unreliable size-only comparison, it still found only 340 duplicates.

Following the advice on a page that recommended five duplicate file detectors, I downloaded and installed Dup Detector.  It was not easy to understand, but some tinkering I was able to get it to work.  The first time I ran it, I told it to search only for 100% matches.  (By default, it was set to search for "Dup if within 98.5% to 100% match.")  The thing that made it work was to go into its Options > "Automatic and Semi-auto delete setup," highlight the "Delete left image" criterion (the only criterion I needed to use in this case) and use the "Swap up" and "Swap down" buttons to make "No delete" come after "Delete left image."  Then, to make it run, I had to start with Get data > Build.  Also, because of the number of files, I thought I had better start with Find > "Find dups setup (method and restrictions)" set to find 9999 pairs.  I still wasn't sure, at the time when I was writing these remarks, whether that was a good number to put there.

When I ran Dup Detector to search for only 100% matches, it found that about half of the PNGs were duplicates.  I eyeballed some of them, using IrfanView to flip through them quickly with just a right-arrow keypress.  There did appear to be a lot of exact duplicates.  I ran an automatic delete to get rid of those dups.  Then I ran a DoubleKiller search for matches that had both identical sizes and identical CRC checksums.  DoubleKiller still turned up 79 pairs of duplicates.  Apparently there had been more than 9999 pairs, first time around.  (If there were more than 100 exact duplicates, then there would be more than 9999 possible pairs.)  To check this, I ran another Dup Detector search for 100% matches.  It found a bunch more.

It seemed, then, that the best strategy would have been to run DoubleKiller first, so as to get rid of one item in each exact pair.  I did that now.  Then I ran Dup Detector, looking again only for 100% matches.  It found none.  I tried again, this time with a search for 99.9% to 100% matches.  Again, it found 9999 pairs.  Some looked identical, in the program's necessarily reduced and imperfect matchup screen, but the differences in others were visible -- more than 0.1% different, I would have thought.  I tried another search, this time adding a decimal point -- looking, that is, for 99.99% to 100.00% matches.

While that was underway, I ran another of the simple comparisons available in ADPF.  It said that, of the 851 pictures remaining (out of the original 1,200), it found 811 similar pictures.  In the bottom pane, I clicked twice on the Similarity column heading, so as to see what it considered the 100% matches first.  I couldn't tell any difference between the ones that I looked at.  I wasn't sure why ADPF had not considered them identical.

Before doing anything with that ADPF comparison, I went back to Dup Detector.  It had completed its 99.99% search.  It was still finding 9,999 pairs.  I had already noticed that, unlike ADPF, Dup Detector was not able to show the right portion (maybe one-sixth) of my widescreen screenshots.  I also noticed that the first line of the Dup Detector report, in the top left corner of the screen, said that it was comparing 99.9% (not 99.99%) matches.  So unless there was a bug in that report, apparently one decimal place was as precise as it got.

I preferred ADPF's visual comparison, so I went back to it.  In the bottom pane, it looked like about two-thirds of its similar pictures were at the 100% level.  That would apparently mean I would have to do hundreds of manual comparisons:  Picture 1 might match Picture 2, and also Pictures 3, 4, 5 . . . I went down to the 99% matches.  These, too, were identical, as far as I could tell.  I had noticed, in IrfanView, that the only thing that had changed since the previous screenshot, among some screenshots, was that the system clock, in the bottom right-hand corner of the screen, had moved ahead by one minute, so maybe that sort of thing kept ADPF from catching them at the 100% level.  ADPF wasn't showing the taskbar or other outer edges of the screenshots, so I couldn't tell for sure.

With hardly any exceptions, I found that even the 95% matches in ADPF were virtually identical.  The only differences that I could detect, in the 50% of less of matches where I did see a difference, was that a different window might be foregrounded -- that, in other words, its title bar would be a different color in one screenshot than in the other.  In other words, the ADPF matching levels seemed more realistic than those in Dup Detector:  this was the kind of difference that I would expect to be detected at the 96% level, well before the 99.9% level.  A 99.9% match, I felt, should involve no more than the tiniest flyspeck of difference.

For my purposes, I did not get regular, visible differences in matches, in ADPF, until I was down at the 91% level.  There were few matches at that level, so I decided to err on the safe side, manually deleting duplicates down to the 95% level.  But in the process, I stopped along the way to re-run Dup Detector.  It seemed I might be able to calibrate it against ADPF.  In other words, I first deleted all of the 100% matches in ADPF, and then ran Dup Detector.  There were about 360 of those, or about 45% of the 811 similar pictures detected by ADPF.  Deleting them was pretty fast, once I got the keystroke combination worked out; it probably took 6-7 minutes.

Rerunning Dup Detector at the 99.9% setting, after deleting ADPF's 100% matches, still produced 9999 matches from the 482 screenshots remaining.  I expected it to produce matches that were extremely difficult to tell apart.  This was not the outcome I got.  There were a number of rather obvious (although still very minor) differences.  It seemed, at this point, that Dup Detector's supposed 99.9% match was not realistic and, for my purposes, not meaningful.  In general, it seemed that Dup Detector had been useful only for purposes of automated deletion of 100% matches, though possibly that function would have been served equally well by an easier DoubleKiller comparison in terms of file size and CRC.  It didn't look like Dup Detector had anything more to offer me at this point.

In the interests of automating future comparisons, I looked around for a free bulk CRC calculator, but ultimately got better results searching for an MD5sum program in CNET.  I thought about FSUM but finally went with the somewhat higher-ranked MD5summer.  Both would do batch work and yield text-file output, but FSUM was command-line.  MD5summer did give me the option of saving its calculated sums as a text file, which I then imported into Microsoft Excel.  Using text parsing functions (e.g., MID, LEFT, TRIM), I extracted the 32-character checksum, sorted, and used a formula to compare cells.  MD5summer had evidently identified only 322 duplicates in 161 pairs.  Possibly the reason the duplicates were found only in pairs was that I had run Shotshooter (above) in 30-second intervals:  there would be only two screenshots per minute, before the system clock changed, producing a screenshot with a different checksum.  That had probably been the case with the DoubleKiller CRC checksum results as well.

One workaround would have been to see if I could conceal the system clock before starting, or I could batch-trim the PNGs in IrfanView (File > Batch Conversion/Rename > Advanced > Crop) before running the checksum, but in this case I wanted the clock to be visible on the output.  (I could also have used cropping, or could have drawn circles and arrows on my PNGs, using something like Photoshop, to narrow the focus to particularly interesting changes on the screen, so as to reduce the percentage match that ADPF or other duplicate detectors would calculate.)  I could have done the batch-trim with a copy of the snapshots backup folder, so as to produce a list of files to be deleted without harming the originals (or, in this case, the copies).  But what if the only thing that changed (in some future application) was a small item in the center (i.e., not at the edge) of the screenshot?  I could use the spreadsheet to identify not only the duplicate pairs but also the time periods during which every minute had a matching pair, so as to lead me toward large stretches of time when nothing would change, and then maybe a manual comparison in ADPF would be manageable for the rest.

So those were possibilities for future projects.  At present, having deleted the ADPF matches down to the 95% level (leaving a few near-duplicates where I could quickly see a difference), I continued on a bit further in ADPF, deleting some additional near-duplicates.  At the 91% level, almost every pair of near-duplicates contained visible differences, so I stopped there.  So I was done with ADPF.

I now had 442 fairly distinct screenshots, out of the original 1,200.  I would have had more if I hadn't abandoned the computer for several hours while Shotshooter was running.  I viewed a bunch of them in IrfanView, again using the right-arrow key to move quickly to the next.  I had already set IrfanView (Options > Properties > Browsing/Editing) to go to the next file after I deleted one -- or maybe it did that anyway, by default.  It now occurred to me that some of my ADPF work might have been faster, and that differences might have been easier to see, if I had just paged through the screenshots (or at least some of them) in IrfanView, using the Delete key (alternately, the X button, up by the menu bar) to delete apparent duplicates.  When I ran into a stretch where there seemed to be many duplicates, I stopped hitting Delete (in case, by deleting too fast, I would accidentally delete one after the screen did change) and instead just selected and deleted many at once in Windows Explorer.

Holding down the right-arrow key in IrfanView allowed me to page quickly through obviously similar or dissimiliar screenshots.  There were still quite a few, requiring as many as 90 virtually duplicate screenshots to be deleted in one case.  It seemed that ADPF may have been fooled, not only by the system clock (which still seemed to be the only thing that was changing, in many cases), but also by relatively complex screenshots (e.g., showing photographic or Google Earth images rather than just text documents, spreadsheets, and Windows Explorer sessions).  That is, to my way of thinking, many of these images were 99% similar, but ADPF hadn't even considered them 91% similar, so possibly its comparison engine was miscalculating similarities in some conditions.

After these other steps, I took a final trip through the snapshots, in IrfanView, and deleted a few more that were very similar to the ones immediately preceding them.  I wound up with 207 snapshots, out of the original 1,200, that seemed to represent fairly well what I had been doing over a 10-hour period.  Again, the number could have been substantially larger -- maybe around 300-350 -- if I hadn't spent a few hours away from the computer.

Now I wanted to put these snapshots into some kind of slideshow.  I rarely made slideshows.  On a few of the screenshots, I decided to use Adobe Photoshop Elements to draw circles and lines to draw attention to changes, from one slide to the next, that might otherwise escape attention.  Then I figured I would use IrfanView (File > Slideshow > Save slideshow as EXE/SCR) to create a slideshow.  (I could also have used something like PowerPoint, except that apparently that would have required me to create 207 slides and then import a photo into each.)  But IrfanView wouldn't let me add circles and arrows or, as seemed increasingly appropriate, a voiceover, to explain what was going on.

I tried using both Adobe Premiere Elements and CyberLink PowerDirector, but neither of them wanted to let me export to a full widescreen format.  Saving it in a reduced format (e.g., 720x480) lost so much detail that it was hard to read what was being displayed.  They also created huge files.  These programs -- especially Premiere Elements -- were also pretty terrible at giving me a simple way of arranging slides.  I wound up just creating an IrfanView EXE slideshow in full-screen mode -- and you know what?  It was beautiful.  Visually, it was perfect.  It looked exactly like the regular computer screen from which I had created all those screenshots.  And it was only 91KB.  Tiny!  The only drawback was that it couldn't incorporate a voiceover and lines and arrows.  So the output side of this project was still in development.

Windows 7: IP Address Conflict: Event Viewer

As described in a previous post, I was trying to resolve an "IP address conflict" error message that would pop up when I connected more than one computer to the NetGear FS605 switch on my home network.  The message, in Windows 7, read like this:

Network Error

Windows has detected an IP address conflict.

Another computer on this network has the same IP address as this computer.

I had worked through a number of possible solutions that did not work for me.  Then one source suggested going into Control Panel > Administrative Tools > Event Viewer.  I had to wait a minute while it read its various events.  In its Summary of Administrative Events, I saw some events whose Source was Dhcp-Client.  This Summary seemed to indicate that details were contained in the Microsoft-Windows-DHCP Client Events/Admin log.  In the Log Summary panel at the bottom of the screen, I looked for a log with that name.  I found one and double-clicked on it.  It opened up a list of 343 events.  I sorted these by Event ID.  Event ID 1001 provided this General error message:

Your computer was not assigned an address from the network (by the DHCP Server) for the Network Card with network address 0x1C6F6541080C. The following error occurred: 0x79. Your computer will continue to try and obtain an address on its own from the network address (DHCP) server.

Event ID 1002 (which, like others below, occurred multiple times) provided this message on its General tab:

The IP address lease 192.168.1.64 for the Network Card with network address 0x1C6F6541080C has been denied by the DHCP server 192.168.1.254 (The DHCP Server sent a DHCPNACK message).

Event ID 1005 was a Warning rather than an Error.  Its General tab said:

Your computer has detected that the IP address 192.168.1.64 for the Network Card with network address 0x1C6F6541080C is already in use on the network. Your computer will automatically attempt to obtain a different address.

Event ID 50034, an Error message, said:

An error has occurred in initializing the adapter 11. Error Code is 0x1004

Chronologically, about half of the events listed on this log had occurred on this particular morning, though I had only been on the computer for about an hour.  Many of them seemed to be spaced about 10 or 11 seconds apart.  I assumed older items scrolled off.  Event 1001 had not occurred in the past several days.  Event 1002 had occurred only once this morning, first thing, when I started up the computer.  All of the events on this log occurred within the first 15 minutes after I restored the computer from sleep (or possibly hybrid sleep).  Maybe that was when this computer B stopped complaining about an IP address conflict.  An Event 1005 was the last one on the log.  Apparently the computer had succeeded, at that point, in finding a different address.

I looked at the Event Log on computer A.  It went back for weeks, so maybe I was wrong about older events scrolling off.  I had installed Win7 relatively recently on computer B.  The Event Log on computer A had the same Event ID numbers.  It also had some others.  On this particular day, it had Event ID 20, which was too long to reproduce here in full, but which started as follows:

The description for Event ID 20 from source Google Update cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

And it also had Event ID 134 on this day:

NtpClient was unable to set a manual peer to use as a time source because of DNS resolution error on ". NtpClinet will try again in 3473457 minutes and double the reattempt interval thereafter.  The error was: No such host is known. (0x80072AF9)

It also had Event ID 315, which said:

The print spooler failed to share printer Brother MFC-7340 with shared resource name Brother MFC-7340. Error 2114. The printer cannot be used by others on the network.

And it had Event ID 1014, which said this:

Name resolution for the name teredo.ipv6.microsoft.com timed out after none of the configured DNS servers responded.

It also had Event ID 4199:

The system detected an address conflict for IP address 192.168.1.64 with the system having network hardware address 1C-6F-65-41-08-0C.  Network operations on this sytem may be disrupted as a result.

There were some other errors that it had not yet had on this particular day.  There were also some that had occurred on this day, but that I have not reported here, at least not yet, because the ones listed above seemed to give me enough to think about for the time being.  These others were Event IDs 8021, 8032, 43029, and 52236.

I looked at the first items of the day.  (These machines were not all set to hibernate or sleep in the same way, if at all.)  On computer A, the first event (other than 43029, "Display is not active") was an Event 4199.  On the Vista laptop, the first event of the day was a 1005, followed by a 4199.  On the WinXP machine, likewise, it was a 4199.  On computer B, by contrast, the first event was Event 1002, and there were no 4199s.  So Event 4199 seemed like it might describe the problem.  I verified that the IP address being referred to on all three machines reporting a 4199 was 192.168.1.64.  (The network hardware addresses reported by Event 4199 varied from one machine and from one Event 4199 message to another.)  That seemed to suggest that I should just reset the IP address on the other machines manually.  I went into IPv4 properties on computer A and changed it to 192.168.1.65.  But I was still unable to go online.  I went into the laptop and tried 192.168.1.66.  While I was there, I noticed that the option to "Obtain DNS server address automatically" was grayed out, and yet there was nothing typed in the manual alternative, so I referred back to my post about OpenDNS and added numbers there.  This did not make a difference on the laptop.  I rebooted and tried again, just in case it would make a difference.  It didn't.  Now I noticed the same thing about computer A, so I added Google's public DNS numbers there.  Somehow -- possibly because I checked the "Validate settings on exit" option -- I wound up in Windows Network Diagnostics on computer A.  It offered this:

Automatically update your network settings
Windows can detect the correct network settings for you.

I thought, why not? and selected "Apply this fix."  It came back with the announcement that troubleshooting had found that "DHCP is not enabled for 'Local Area Connection.'"  And maybe that was true.  But computer A was still not going online.  I went back and saw that it had wiped out what I had just entered.

I noticed, when I went through the troubleshooter on computer A just a moment earlier, that it had the temporary effect of making computer B unable to go online.  I just happened to be at this blog post, and perhaps Blogger was trying to save at that very moment or something.  Anyway, a moment later, Blogger was able to save again.  I was curious about this, so I went back into Event Viewer, sorted for date and time, and hit F5 to refresh.  But no, there were no more recent items, so apparently whatever had happened had been too brief a blip to register on the log.

I tried typing ipconfig in a command box (Start > type "cmd" > type "ipconfig"), on computer A, to see what IP address I had now.  My change to 192.168.1.65 had stuck.  And yet it could not go online.  How was the 65 address conflicting with the 64 address?  Didn't make sense.  I refreshed Event Viewer on computer A.  (I accidentally refreshed this post instead.  Thanks to Blogger, that scrambled what I had written here, so I had to go back and fix it.  That took maybe 20 minutes.)  The last events in Event Viewer on computer A included a 1005 reporting that 192.168.1.64 was already in use on the network.  But ipconfig on computer A reported an IPv4 Address of 192.168.1.65.  So, OK, maybe no more IP address conflicts?  But computer A was still unable to go online.  I rebooted it.  The situation was the same.  The IP address was definitely 192.168.1.65, and there were no new events in the log (from the past 25 minutes or so), and yet I couldn't browse online.  In the command box, I got results from "ping www.ehow.com" on computer B, but not computer A.

On computer B, I went into Control Panel > Network and Sharing Center > Troubleshoot problems > Internet Connections.  That troubleshooter again offered to change my settings.  Since it didn't work last time, I skipped it this time.  It reported the same "DHCP is not enabled" error as last time.  A search for that error led to comments about routers.  Suddenly it occurred to me:  was 192.168.1.64 the only address that the modem was making available -- was that how this worked?  (Note:  I had since discovered that my modem was actually a combination modem/router.)  Consulting my previous post on the modem's part in this drama, I logged into the modem's internal webpage and looked around.  It said that, on the local network, the modem's IP address was 192.168.1.254, but that wasn't what I wanted to know.  That was where I could log into the modem, as I had just done.  But going in the opposite direction, where would the modem find computer B?  There was a log here, too, and it had a bazillion entries saying things like this:

2011/01/15 8:25:35 GMT - L3 - DHCP: Address 192.168.1.64 declined

The date and time reported there were just a few hours earlier.  So it was listening to computer A; it just didn't like what it was hearing.  On the modem's Statistics tab, I found a section containing "LAN Information."  This section reported that the DHCP address was 192.168.1.64.  So maybe that was the address that the switch was supposed to be using?  And then the switch was supposed to generate new IP addresses that the computers could use?

There was a "Routing Table" that seemed to say my ethernet network was connecting to the modem at 192.168.1.254.  That was the "Modem IP Address."  Further down, I saw a "Devices on LAN" section.  This listed two IP addresses as Active.  These were 192.168.1.64 and 192.168.1.65.  It listed two other addresses as Offline.  I hadn't seen those before.  I didn't know what those were for.  The 192.168.1.64 address looked like it was being associated with computer B -- the computer name it showed was partly familiar to me.

I wondered if this table would change if I changed things on the network.  So I unplugged the ethernet connections from the switch, for all computers except computer B.  Then I hit F5 to refresh the modem's webpage.  The name shown for computer B changed slightly, but otherwise these things seemed to be the same.  So the "Devices on LAN" section seemed to be listing all of the addresses from which computers had ever (or at least recently) tried to access the modem.  To test that, I unplugged computer B and plugged in computer A.  On computer A, I changed TCP/IPv4 Properties to specify an IP address of 192.168.1.66.  Sure enough, now the modem's "Devices on LAN" webpage was reporting a fifth entry, for that IP address.  The "MAC Address" reported for 192.168.1.65, on the modem's statistics page, was the same as reported for 192.168.1.66.  Apparently the MAC address was the "network hardware address" referred to in Event 4199 (above).

The modem's statistics page reported, as I say, a DHCP address of 192.168.1.64, and it reported a device on the LAN -- namely, computer B -- at that same address.  Did this mean that computer B was hogging the only available address of 192.168.1.64?  On computer A, I went back into TCP/IPv4 Properties and changed the IP address to 192.168.1.64.  With only computer A connected to the switch and therefore to the modem, I refreshed the modem's webpage.  Now it reported that 192.168.1.64 and 192.168.1.66 (but not 192.168.1.65) were Active, and the name of the computer at IP address 192.168.1.64 was simply "192.168.1.64."  Three of the five items in the Devices on LAN table had identical MAC addresses -- presumably that of computer A.  (The other two were 191.168.1.107 and 125.)

Unfortunately, computer A was not able to go online at this point, even with no other computers connected to the switch, or even with computer A connected directly to the modem.  I wondered if this was due to an internal conflict, in the sense that it now had these three identities.  I did a search for information related to my Motorola model 2210 modem and found a thread where someone said this:

Only one device can be set up as a dhcp client with the 2210.  All other devices will require a static private IP address.

Well, this was daylight.  Another person explained:

The DHCP server will assign only a single IP address, 192.168.1.64. It will be assigned to the first device which makes a DHCP request. Additional DHCP devices will be declined an IP address.

This raised the question of what would have happened if computer A had been the first one to contact the modem.  (For posterity, my search led to a manual for a Motorola 2220, which was apparently similar to the 2210 but had more features.)  To test that, I unplugged the modem and let it sit.  Meanwhile, I changed TCP/IPv4 properties in computer A to obtain and IP address and DNS server address automatically.  Then I powered up the modem, and after it was back online I viewed its webpage from computer A.  That did it.  Under Devices on LAN, it showed only 192.168.1.64.  And it appeared I was right about the internal conflict:  computer A was now able to go online.

It felt, at this point, like the Event Viewer had introduced me to something resembling an intelligent way to resolve networking problems.  I had miles to go.  But this was starting to make sense.  So now, what would happen if I connected computer B to the switch?  I did that.  Now computer B was reporting an IP address conflict.  Computer A wasn't, at least not yet, and ipconfig there continued to report an IP address of 192.168.1.64, but now computer A was not able to go online in the web browser, though it did successfully ping http://www.ehow.com/.  The modem's webpage, duly refreshed, oddly still reported only one Devices on LAN:  192.168.1.64.  I was not presently clear on the name of the computer it was associating with that IP address, but tentatively it appeared that the computer that first approached the modem after a reset would be the one whose real name (i.e., the name I had assigned to it during Windows installation) would appear in the modem's Devices on LAN list.  (The modem's log, which I had erased with the reset, now reported a bunch of new "DHCP: Address 192.168.1.64 declined" errors.)

I still didn't understand why computer B would still gain dominance in terms of Internet access, when both were connected, even if computer A was the one associated with 192.168.1.64.  Life wasn't as easy for computer B this way -- when it wasn't first to the modem, it seemed to struggle more to get online when both were connected to the switch, but ultimately it was able to do so, displaying webpages after one or two refreshes if not right away.

The modem's webpage, viewed on computer B, was hung at this point -- it wasn't reporting statistics, just sitting there with that Win7 spinning hourglass, telling me that it was thinking about it -- so I ran troubleshooting on computer A.  It said, "'Local Area Connection' doesn't have a valid IP configuration," and it said it had fixed that.  Then I was able to see that computer A remained the only item listed in Devices on LAN.  But computer A (and not computer B) was still reporting an IP address conflict, and still couldn't view webpages.

Following another thread, I checked the modem's webpage for information on its range of available addresses.  But there didn't seem to be one.  Even if I found one, it would presumably make no difference.  The modem was going to work only with 192.168.1.64.  Assigning other static IP addresses would apparently not help.  But why would it be better to let computers acquire their own IP addresses, if 192.168.1.64 was the only one available?

I did a revised search.  This led to a webpage with several suggested steps to resolve DHCP problems.  The webpage said that an IP address conflict was one kind of DHCP problem.  It suggested typing (in a command window) "show ip dhcp conflict:".  I tried that.  The reply was, "'show' is not recognized as an internal or external command, operable program or batch file."  An old thread offered this interesting theory, about a system having a modem like mine:

The modem will only hand out one LAN IP address on the network. So the first device to request an IP will be the one to get it. If another device makes a request for an IP it will be denied and that computer will not have internet access.

Another poster in that thread revised that:

Slight correction, the last device to request an address is the one that gets it. So if you have two devices active at once you will get address stealing from each device as the DHCP leases are renewed.

Neither of these seemed to explain what was actually happening on my system.  Any way I sliced it, computer A was the junior partner.  I tried a revised search and then turned to a missing piece of the puzzle:  how did the switch work?  That was a matter for another post.