Right around the same time that Windows RTM was posted to TechNet and MSDN (August 6), reports began to surface that Windows 7 was suffering a bluescreen when users would run the CHKDSK utility with the /r switch selected (which locates bad sectors and recovers readable data from them). See this 8/5 Gizmodo item as a good example of the kind of reportage that swirled around the Web in the wake of initial reports on this problem: Windows 7 Has an Obscure OS-Crashing Memory Bug (or visit Bing or Google using “Windows 7 chkdsk /r crash” as the search string). As you might imagine, furor and hysteria soon followed, and subsequent reports from MS that confirmed high memory as a deliberate design choice to limit ongoing concurrent use of the affected PC (who wants to use a machine with a bum disk until it’s repaired anyway?) and indicated that crash conditions were not reproducible did little to quell the uproar.
Today, just over three weeks later, the hubbub has died down. That’s why I found MS VP Steven Sinofsky’s detailed posting (the blog is signed only “Steven” so I assume this means him, though I’m happy to be corrected if I’m wrong about this) on the Engineering Windows 7 blog to discuss this item fascinating, even though it appeared on 8/10 and I just stumbled across it just this morning. It’s entitled “What do we do with a bug report?” and makes for some compelling reading. He not only digs into the particulars of this particular Windows 7 problem, he also reflects on how MS deals with bug reports, especially when they involve mention of bluescreens or other system crashes.
What I found most interesting in this posting were the following revelations:
- MS has access to a lot of data about crashes and errors, thanks to the many users who turn on error reporting during the Windows installation process and elect to share that information with Microsoft. His discussions of telemetry and the kind of information it can provide are terrific, and help to explain why you might agree to those information sharing and improved experience requests, the next time you install an MS product.
- MS uses some interesting test approaches to try to reproduce and understand crash situations. Sinofsky talks about how they use configuration data to set up test environments, and how they reach out into the tens of thousands of in-house users in their own community to see more data than might otherwise be at hand. We’re talking hundreds upon hundreds of test runs going in a pretty short period of time.
- Though I’m sure some of his rhetoric and discussion is easy to interpret, and possibly even to dismiss, as “executive damage control,” I gotta say I was impressed by how clearly and concisely he described the overall situation, and put it into the more general context of bug reporting and resolution processes at Microsoft. I’ve already noticed that my own error reports from Windows 7 tend to produce more updates and eventual solutions from the Action Center, than they ever did from the error reporting facility in Windows Vista. Now, I’m starting to understand why this might be the case.
Check out this blog. I’m sure you’ll find it both interesting and informative.
Take a look at the Reliability Monitor output for my production PC, which has been running Windows 7 since my birthday on August 8. In addition to showing why I’ve got a new motherboard waiting for me to have time to swap out with its current Gigabyte P35T-DQ6 motherboard, it also shows no numerical values for the reliability index on any given day. I’ve highlighted the most recent Windows OS failure on 8/19/2009 by way of illustration, but what I want you to note is that while you can eyeball an approximate value for the RI (reliability index) on any given day — 8/19 looks like about a 6 to me, for example — the utility no longer reports a number anywhere in its display. Of course, that number has to be around somewhere, because the utility couldn’t draw the graph without numerical data from which to plot the points.
On my Dell D620 notebook running Vista Business, however, Reliability Monitor is happy to show me an index value for any day I select, as indicated here:
During the beta period I tried like the dickens to contact the MS beta team and tell them to please add this back in, but I’ll be darned if I could ever figure out how to get into the proper channel to deliver that feedback, let alone share it with somebody who could actually *do* something about it. Now, all I can hope is that somebody at MS will see this lament and get it scheduled for Windows Update inclusion. I think we all deserve to know what our RI value is, rather than having to guess! What say you?
Part of what I’ve been learning lately as I slowly but surely upgrade all of my PCs to Windows 7 has been about the dynamics of working with networking/LAN resource access. Although my understanding of homegroups and printer access has been proved more right than wrong in concept of late, my recent experience has also showed me a few wrinkles that I didn’t know about, and that others may not anticipate until they stumble across them themselves, or read about them here or elsewhere. Please allow me to explain…
One of the nice new additions to the Windows 7 environment is an interfac entry entitled “Devices and Printers” that shows up in the bottom section of the right-hand start menu along with Control Panel, Default Programs, and Help and Support. Here’s what this currently looks like on my production machine.
You’d think that discovery of printers on a network with Windows 7 machines is simple and straightforward, wouldn’t you? If you have turned on File and Print access, you’d expect that UNC names for the printer of the form \\PC-name\Printer-name would work like a charm to gain access in the Add a Printer wizard. Not so — at least, in my experience. Even making sure that both sides of the connection (would-be printer user, and would-be print provider) had File and Print access enabled, and belonged to the same workgroup didn’t do the trick in all cases (it did for two out of three machines, but not for all three).
The “trick” — if there is one — turned out to be setting up a Windows 7 Homegroup and making sure all machines that wanted to use the printer, as well as the machine that hosted the printer, belonged to that Homegroup. My earlier understanding of Homegroup membership was that it added to existing Windows capabilities, so that if you didn’t take this step, you could still revert to old-fashioned UNC names to obtain device access at the NetBIOS level. I’m not sure if this is just an idiosyncracy for one of my machines, or a general tendency for Windows 7, but I couldn’t get everything to work properly on my network until all my machines had joined the same workgroup. After that, proferring or obtaining printer access across the network was a snap.
I can’t help but guess that this won’t affect AD environments, but if you run into strange printing problems there with Windows 7, drop me a line and let’s figure out what’s going on there, too. Could be interesting!
Back in 1994, I traded a copy of NetWare 4 50-user with a reseller for a brand-new HP LaserJet 4M 600-dpi PostScript model. It’s stuck with me through two versions of Windows NT (3.51 and 4.0), Windows 2000, XP, and Vista, plus Windows Server versions through 2008 (R1). I was pleased to be able to find a driver for this old but still reliable beast for Windows 7 through Windows Update but alas, it didn’t work properly (at least, not at first): instead of printing like it did under XP or Vista without a hitch, I got an “invalid font” PostScript error message and the unit failed to print its test page.
Although my unit is indeed as described above (HP LaserJet 4M Plus PostScript 600 dpi) and a driver for that precise model is available, I had to downgrade to the plain-vanilla HP LaserJet 4M Plus driver to get this printer to work with Windows 7. It’s interesting to me that the I see the biggest-ever collection of drivers for this ancient printer model with Windows 7, but also that while the most specialized driver fails to work properly, the more generic version does just fine.
You could certainly say this printer has provided plenty of service in the 15 years I’ve been using it for work and personal use. It’s definitely the longest-lasting piece of computer hardware I’ve ever used, and I’m sorry to see it headed for retirement. I’ve ordered a new, top-rated 30 PPM Samsung ML-2851ND workgroup printer to replace this power-hungry monster, and will be curious to see how it performs in its place. It’s also amusing to me that despite the huge advances in laser printing technology since the LaserJet 4M first made the scene in the early 1990s, toner cartridges for my new printer and my old one still cost about the same (approximately $100 for a brand-new cartridge from the vendor; about $80 for a refill from a third-party supplier including old cartridge recycling). That said, the $900 MSRP price for the 4M at the time I acquired it has dropped to a paltry $170 or so for its Samsung replacement, lo these many years later (about $122 1994 dollars in 2007, according to this CPI conversion tool). That’s quite a major price reduction in the printer, but these days selling printers is all about selling consumables (ask any inkjet owner! ;-).
It’s not so much that I absolutely must have 600 dpi output that led me to make the retirement call for my trusty LaserJet4M. Rather, it’s a combination of increasingly difficult availability for parts and toner cartridges, higher power consumption, and its size and heft that all conspired to bring me to this pass. I have to imagine that the introduction of Windows 7 into other workplaces will provoke other, similar changes to familiar features on the IT landscape as well. At a bare minimum, it will be nice to bring my printing infrastructure entirely into the plug-and-play (PnP) era. Although Windows Update was able to find and deliver lots of drivers for this older HP printer, who knows how long that can remain the case?
I’m thinking about dropping the old 4M off at a nearby Goodwill recycling center in Round Rock as soon as the replacement unit arrives (probably on August 28)— unless somebody in the Austin metro area wants to come pick it up and give it a new home at no cost (it’s got a brand-new toner cartridge installed). Drop me an e-mail or post a comment to this blog, if you’re interested. The unit’s printed less than 150,000 pages and the print engine is rated for 250,000 so the old girl’s still got a few good years left! PLMK.
[Update on 8/27: I’ve got a taker for the printer, so please don’t ask if you can have it. It’s already spoken for! The early bird gets the worm, and the first request got this printer. I guess it’s still worth something after all. ]
At about 10 this morning, I started working on the upgrade from Windows Vista Ultimate to Windows 7 Ultimate. As always, my efforts began with an image backup, so that in case anything went wrong, I could get myself back to where I started without too much muss or fuss. This time, I used the built-in Vista image backup facility: I know from repeated experience that I can use it in tandem with an install disk (of which I have a surfeit at the moment, thanks to my recent work on a spate of Windows 7 articles and a bunch of chapters for a book) to put my system back into action even when the system drive won’t boot.
Surprisingly, the JMB36X driver issue that the standalone Windows 7 Upgrade Advisor flagged as a potential problem (see my previous blog) wasn’t flagged when the upgrade compatibility check ran, nor did it warn me about potential problems with the version of Visual Studio 2008 I’ve got installed on this test machine. It did, however, puke at IntellType 7.0 and at PerfectDisk 10, both of which I had to uninstall before I could proceed with the upgrade install for Windows 7. IntelliType vanished without a trace, but I had to delete the Raxco directory (where PerfectDisk and its install files go by default) as well as uninstall the program to get an “all clear” from the installer. Fortunately, I did some work for Raxco last year and got my favorite tech support person on the phone when a simple uninstall didn’t do the trick, and he pointed out that the installer probably scans the hard disk to look for potential offenders and was still seeing the PD10.exe file, even though it was no longer runnable. Deleting the whole PerfectDisk directory tree did the trick.
Getting those preliminaries taken care of took about an hour. Then I started the Windows 7 Ultimate upgrade install. Because of the numerous programs on this test system (Revo Uninstaller and Programs and Features both report 66 applications installed) rather than taking half an hour to complete — as it typical for a clean Windows 7 install — it took about 75 minutes to get through the process, much of which occurred while a splash screen reading “Upgrading Windows” was the only GUI information available to my curious but soon glazed-over eyes. When the upgrade process concluded, the installer automatically launched for Windows Live Messenger, which apparently needed to be reinstalled once Windows 7 was up and running. Also, the first time I ran Internet Explorer 8.0, I once again had to go through the initial configuration steps, as if I’d just installed it for the first time. Total time consumed so far at this point was about 3.5 hours.
Then I started checking drivers. I’m pleased to report that all of them came through the upgrade unscathed but that’s probably because I’d made sure all the drivers were current for Vista just before I ran the upgrade install. That said, I’m starting to see a whole slew of Windows 7 drivers show up on vendor Web sites, and have recently grabbed new Windows 7 drivers for RealTek (networking and audio), JMicron (JMB36X RAID controller), Logitech (SetPoint 4.80 is out and works with Windows 7 thought they still claim not to support the Windows 7 RC and RTM isn’t yet officially “out”), and even Microsoft itself (new versions of IntelliType and IntelliPoint are out and ready for Windows 7). Total time elapsed to make the upgrade was just under 5 hours: not at all bad considering the same move from XP to Vista regularly takes me more like 10-12 hours (but then, drivers are totally different between those two OSes, and Vista and Windows 7 use the same driver model and by and large also run the same drivers).
I’d have to rate this exercise a success, if still not completely simple and straightforward. Sure beats previous upgrade experiences, and all my applications appear to have survived the translation unscathed. Yippee!
Last Thursday, I suffered a BIOS flash problem on my primary test machine that resulted in a completely dead motherboard: no post, no action at startup except for lights and fan up, followed by an immediate shutdown. A little research showed that my Asus P5K is one of a very few modern motherboards that can be reduced to inert circuitry by a BIOS flash error. A quick $20 to a chip supplier on ebay got a new chip on its way to me in the mail, but I had to have another machine to mess about upon as soon as possible.
I decided to resuscitate my previously moribund Windows Vista Media Center PC, which includes a Gigabyte X38-DQ6 mobo, a QX98650 quad core CPU, a GeForce 8800 GT, 4 GB DDR2-800 RAM, and about 1 TB of putative disk storage. In short: a state-of-the-art PC in 2007 when it was put together, and a decent system even by today’s standards.
To re-start my upgrade install experiment on a machine sitting idle since last December (at least, as far as its disk drives were concerned; we used this machine for other testing in the meantime, but on different HDs), I first had to do the following:
- Reactivate my anti-virus and anti-spyware packages, and bring them up to date
- Apply over 40 items from Windows Update to the 32-bit resident version of Windows Vista Ultimate
- Make the drivers current and up-to-date (DriverAgent now reports only one out of date driver, and that’s for a disconnected device which worries me not at all)
- Install my full complement of applications, just to see what would have to go and what could stay as Windows 7 works through the upgrade process
- Make an image backup of the system, so I would have a place to go back to in case the upgrade should fail for any reason
Altogether, this process took a long day to complete (though I kept working on other stuff on my production machine all along, so it didn’t keep me from taking care of my more usual business).
Over the weekend, I got started on the upgrade process, kicking things off with the still-beta version of the Windows 7 Upgrade Advisor (I can’t find a newer version of this available just yet, so I guess MS doesn’t feel itself on the hook to deliver same until the official GA date for Windows 7 rolls around on 10/22/09). When I ran the program via a remote desktop connection it fired off without a hitch, but proceeded to grind away for 25 minutes, before I gave up and tried again at the machine’s local controls. This time, it finished in a mere 3:25 before tendering its compatibility analysis.
Based on my earlier failed venture I expected to see some programs in need of removal, and wasn’t sure if all the hardware on this system would pass muster. After it identified my JMicron JMB26X RAID controller driver as a potential sticking point, I visited the vendor’s FTP site and downloaded then updated the 184.108.40.206 driver to the latest WHQL 220.127.116.11 drivers instead. After that I re-ran the Upgrade Advisor to produce the following screens (which still didn’t do away with the JMicron JMB36X warnings, even though my production system is running Windows 7 quite happily with the 18.104.22.168 drivers, and what I have on the test machine is much newer).
Here’s the base level report that the Windows 7 Upgrade Advisor (beta) produced:
Here’s a shot of the devices page from the UA, with the warning about the JMB36X controller featured prominently at its head.
It’s a real relief when everything — or as in this case, nearly everything — comes up with a clean bill of health, hardware-wise. Given that my other machine includes the same RAID controller and is working famously with Windows 7 on an older version right now, I’m not too concerned anyway.
Here’s a shot of the requirements page from the UA, which shows that my test machine exceeds the various minimum/recommended requirements:
I’m reading reasonably reliable reports that this motherboard works with all four DIMM slots occupied (my earlier P35 models couldn’t handle all four slots filled) so I’m also going to install 64-bit and try 12 (2×4 plus 2×2 GB) and 16 (4×4 GB) RAM in this rig as well. But let’s save that for another day.
There’s also a minor warning about the version of Visual Studio I have installed on this machine, but I’ll cross that bridge when I next turn to those tools on that machine (count on me to report back if anything untoward presents during that process). Frankly, I’m not too worried about it. My only beef with the driver warning from the UA is that it gave me no idea which version I should use instead, and I gave up after trying the three most recent versions on the vendor’s FTP page and still not getting it right.
At this point, I’m ready to run the upgrade install. I’ll report on my experiences in performing that upgrade in my next blog, the day after tomorrow (August 19).
Starting with Windows XP, but especially in Windows Vista, I learned to appreciate the Windows Repair Console. This utility made itself available through the Windows install media, and could be elected after booting from the CD or DVD for one of those OSes through striking the R key to initiate a repair install (XP) or by choosing the System Recovery Options during the install process (Vista). These tools saved my hindquarters more than once after unfortunate boot option selections or registry edits led my PC astray, and even enabled me to load restore points or grab image backups to replace a completely busted installation with a working setup.
While I was working with the Windows 7 beta I must have been too chicken to deliberately bust my installations at the time, but since the RTM has become available–I started downloading last Thursday, and installing last Friday, and am still in the thick of updating production and test desktops, as well as notebooks and netbooks galore–I’ve already managed to mung at least two machines while playing and messing about with those systems.
To my surprise and delight, the Windows 7 on-disk image includes the Windows Preinstallation Environment (aka WinPE) and the system recovery options. When the system can read enough of the system disk to grab those files after encountering trouble, it will load this environment automatically and run it for you to help you repair your installation. Although it’s also still included on the install media (and will come in very handy when the system disk gets too badly trashed to find and/or run those files) its automatic invocation from the hard disk has proved to be both handy and helpful. Though I can lay hands on at least four flavors of Windows 7 install DVDs at the moment (so far I’ve burned them for both 32- and 64-bit versions of Professional and Ultimate), it’s even more convenient for the OS to notice that it isn’t starting up correctly or that key system files have been damaged, corrupted, or gone missing, and to invoke WinPE and the system recovery console on your behalf.
So far, I’ve used it to replace some damaged OS files and to recreate my MBR and Windows boot environment with great success. The WinPE environment starts up in less than 30 seconds on those machines where it’s been brought into play, and has been able to fix such problems as I’ve stumbled into so far in my continuing Windows 7 adventures. To me, it’s just one more thing to like about the Windows 7 environment.
Having upgraded my primary production machine to Windows 7 over the weekend (see my recent ViztaView blog for those details) I’m now really settling in with the new OS and learning to live with it on a daily basis. Though I do have 6 months of uniformly positive experience with various Windows 7 beta releases from Build 7000 to 7100 (the release candidate, or RC), only now am I truly living and breathing this OS on the machines that matter most to my day-to-day working success: my primary desktop and notebook machines (one for work in the office, the other for work on the road) and my Big Kahuna test machine (where I now use VMs to play host to any and all of the myriads of software that I regularly investigate, test, and review).
Over the past few days, my primary production desktop has manifested a black screen for about a second on my primary monitor (a Dell 2707 WFP running at 1920 x 1200 resolution) perhaps three or four times a day. Yesterday, finally, this persisted long enough to generate a Windows error message through the Windows 7 Action Center:
With this information in hand I moseyed on over to the Nvidia Drivers and Downloads pages and discovered that indeed a new driver version was available for my GeForce GTX 275 graphics card. I’ve downloaded and installed it, and can report that it specifically mentions Windows 7 among its list of supported OSes (which is more than the previous 22.214.171.12435 did) and that I’ve had no further problems of this kind since that installation. But of course, the day is still young…and here is the complete list of issues that Windows 7 has detected on my machine so far today:
Now, the real sleuthing work begins and I really start to get to know Windows 7. Most of my learning is problem driven at first, and it looks like I will have plenty of food for learning and thought as I begin to dig into the day-to-day rhythm of working with this new OS.
I stumbled across an interesting TechNet Step-by-Step piece this morning as I started researching the Vista to Windows 7 migration subject. I just upgraded two machines over the weekend, in the wake of the RTM release to MSDN at noon CDT on Thursday. Once the downloads were completed (that took until just past midnight Friday night, in my case to get 32- and 64-bit copies of Windows Professional and Ultimate), I started cranking away at installs for my 64-bit test machine (which also got an upgrade to 12 GB RAM at the same time) and for my 32-bit production PC as well.
The formal title of the TechNet piece is “Step-by Step: Windows 7 Upgrade and Migration.” Here’s a screen shot snippet that shows the lead-in and library entry info:
If you dig into this story, you’ll find useful instructions for the following topics covered:
- Upgrade from Windows Vista to Windows 7
- Migrate files and settings to a new computer
- Upgrade from Windows XP to Windows 7
To those scenarios, I’d also recommend that organizations with some budget also look into the Laplink one-time upgrade/migration licenses. These retail for $65 each on a one-off basis, and can probably be purchased in bulk at some kind of discount (hopefully substantial), and permit applications to be migrated along with files and settings from most older Windows OSes (especially Vista and XP) to Windows 7. This can make the job of migrating machines must easier for admins who may need to do this pronto for some existing installs.
Let me also observe that my experiences in installing Windows 7 so far have been uniformly positive and mostly-problem free. If you want the gory details check out this morning’s ViztaView blog “No Joy on In-place Upgrade; Clean Install Succeeds,” wherein I provide a blow-by-blow recitation of my recent experience in moving my problem-plagued production PC from Vista to Windows 7, with 98% positive results and a solution for all my software problems along the way.
At this very moment, I’m about 80 percent done with my first of four planned downloads for Windows 7 from MSDN. Alas, my Vista box did go to sleep last night despite the ongoing download, so it didn’t resume until this morning to finish up. Now I know to turn off sleep mode on this machine until the rest of those downloads complete, and because the 32-bit version of Ultimate is last on my list (wouldn’t you know it) I probably won’t get that version until later today or perhaps even tomorrow. It’s the one I need to try out the upgrade on my balky and temperamental production desktop machine. Why didn’t I put it first on the list? Oh yeah: because it’s lower down on the MSDN download page. Sometimes I wonder…
Here’s a snapshot of my current progress:
There is some good news on the download front this morning, however: my transfer rate is bouncing between 250 KBps and as high as 450 KBps. That sure beats the sub-100 KBps rates that prevailed yesterday, and means I might actually finish all three remaining downloads in far less time than the first one took to complete. At least, I certainly hope that’s the case! As I post this blog, I’ve already jumped to 87 percent complete on the first item, so there may indeed be cause for optimism.
[Update at 9:53 AM, 8/7/09: first download completed and now being validated. Let’s hope it passes!]
[Update at 3:39 PM, 8/7/09: fourth download underway, transfer rates down below 30 KBps for a total transfer time of 26-30 hours: looks like the 32-bit versions are getting hammered, with the 64-bit versions coming more than 10 times faster. Does that indicate the current ratio of 32-to-64 bit installations (about 11 to 1)? I sure think so…]
[Update at 11:07 PM: broke the Akamai connection to reboot after updating to Logitech SetPoint 4.80 drivers just released on 8/5. Bingo! A new connection is running consistently at 400+ KBps. Maybe I’ll get this downloaded before I crash tonight after all…]