September 4, 2009 3:56 PM
Posted by: Ed Tittel
Asus P5Q3 motherboard
, Gigabyte P35T-DQ6 motherboard
, Windows 7
, Windows 7 Reliability Monitor
, Windows hardware compatibility issues
Those who’ve been reading this blog for any length of time know I’ve been fighting with a balky, or perhaps blighted, production PC for some time now. I upgraded this machine to Windows 7 in early August in hopes that it might help with chronic instability issues. Since then, results had been mixed with reliability index values fluctuating between 4.8 and 7.0 or thereabouts (in Windows 7 it’s kind of hard to tell because the Reliability Monitor no longer reports numeric values for that index, so you must eyeball it from the scale at the left of the graph). But over the past 10 days my system has experienced what mathematicians call a “montonically increasing” pattern, which translates into plain English as “upward and onward.”
Reliability Monitor as of 9/4/2009
I can’t tell if I’m at a 10.0 value, or simply approaching that value, but this is probably the highest reliability index I’ve ever seen on this machine. And of course, that raises a very interesting question: should I just leave this machine alone and keep on going with what I’ve got, or should I tear it down and install the processor and other components on the new Asus P5Q3 motherboard I ordered a couple of weeks ago to replace the Gigabyte P35T-DQ6 motherboard that’s currently in there (I had also planned to move the system into a bigger, better-ventilated Antec 900 case, and use an SSD for the boot drive)? I’m mindful of the old saying “If it ain’t broke, don’t fix it” — we are talking about my production machine after all. But then, I start to recall all the aggravation and heartbreak this machine has caused me in the past year, and wonder if this isn’t just a lull between storms.
I’m probably going to sit tight for a while because I’ve got to build a machine for my wife, for whom I just bought a barebones compact system built around an MSI Core 2 Duo Mobile motherboard (945GME1 mini-ITX model) and a Morex 150-Watt compact mini-ITX case with an Intel Core Duo T2300 processor (1.66 GHz). I’ve got SO-DIMMs out the ying-yang, and a 5,400 RPM SATA 2.5″ 160GB drive scavenged from my MSI notebook ready to install in that unit. I think I’ll do that system first, and also install my new Samsung monochrome laser printer, and use that interval to see if the good behavior from my production system is a glitch or the real thing. And if it ain’t broke, I may very well NOT fix it, but may take advantage of sub-$200 prices on Core 2 Quad Q8XXX CPUs to build a new test system re-using the case and power supply from my wife’s now-retired Sempron 3200+ system that gave up the ghost a couple of weeks ago.
More on this as the situation develops. Tell you what, though: I’ll be astonished if my production system has finally settled down. We’ll see…
August 28, 2009 2:52 PM
Posted by: Ed Tittel
, Windows 7 bug resolution
, Windows 7 chkdsk crash
, Windows 7 error reporting
, Windows 7 quality control
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.
August 27, 2009 9:52 PM
Posted by: Ed Tittel
Windows 7 reliability index reporting
, Windows 7 Reliability Monitor
, Windows 7 shows no numeric reliability index value
No numeric index value appears in the Win7 Reliability Monitor
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:
Notice the Index number value at upper right
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?
August 27, 2009 8:52 PM
Posted by: Ed Tittel
Windows 7 and use of UNC device names
, Windows 7 homegroups
, Windows 7 network printer access
, Windows 7 printer sharing
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.
Devices and Printers shows what is installed on your Windows 7 PC
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!
August 24, 2009 2:16 PM
Posted by: Ed Tittel
HP LaserJet 4M Plus drivers for Windows 7
, Samsung ML-2851ND workgroup laser printer
, Windows 7 update printer drivers
, Windows 7 upgrade
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. ]
August 19, 2009 9:05 PM
Posted by: Ed Tittel
migrating from Windows Vista to Windows 7
, Windows 7 upgrade install
, Windows Vista Ultimate to Windows 7 Ultimate upgrade
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!
August 17, 2009 6:58 PM
Posted by: Ed Tittel
Windows 7 driver issues
, Windows 7 upgrade
, Windows 7 Upgrade Advisor beta
, Windows 7 Visual Studio 2008 minor issue
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 188.8.131.52 driver to the latest WHQL 184.108.40.206 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 220.127.116.11 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:
Almost everything comes out of the Win7UA clean
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:
No problems with the requirements on this rig
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).
August 14, 2009 12:15 PM
Posted by: Ed Tittel
Windows 7 installation and setup
, Windows 7 repair install
, Windows 7 system recovery options
, Windows 7 WinPE OS repair
, Windows 7 WinPE startup repair
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.
August 12, 2009 7:25 PM
Posted by: Ed Tittel
Windows 7 black screen
, Windows 7 driver problem
, Windows 7 KSOD
, Windows 7 NVidia driver problem
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:
At some point, my brief graphics outages triggered a Windows 7 error message.
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 18.104.22.16835 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:
Also on my hit parade: Outlook goes south, and a .sys file has ACL issues.
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.