Hey! Big new on Brandon LeBlanc’s Windows Blog for June 23. It’s entitled “150 Million Licenses of Windows 7 Sold…” and goes on to make the claim that this version of Windows is “…the fastest selling operating system in history with 7 copies of Windows 7 sold every second.” Does this mean we can finally all stop moaning and groaning about Vista? Gosh, I certainly hope so, because the total and the run rate are both pretty considerable numbers.
LeBlanc’s blog also goes on to mention this interesting factoid as well: according to Tami Reiller’s keynote at the BofA/Merrill Lynch Technology Conference earlier this month, a whopping “…75% of enterprises are looking at Windows 7 for their organization.” A recent Lifehacker study on Windows 7 user satisfaction reports that 72% are absolutely satisfied with the OS, and that 22% designate themselves as “I’ve got some complaints, but overall I’m happy.” Microsoft combines these numbers to report that 94% of all Windows users are “happy” with the OS, though maybe “some kind of happy” might be a bit more on the mark. Likewise a recent Gartner study that Tom Bradley at PC World covered on May 26 predicts 22% growth in global PC sales for 2010, which Bradley (and Microsoft) are more than happy to attribute not just to the global economic rebound — such as it is — but also to “…the success of Windows 7.”
Looks like things are looking up for Windows 7, and if you don’t have it on a desktop near you (or your own desktop, in fact) already, it should be showing up there sometime soon.
According to MS KB Article 983551 (6/10/2010; Rev: 2.0) some computers running Windows 7 or Windows Server 2008 R2 can freeze at the “Please wait” display that precedes appearance of the desktop on your screen. Alas, because of a deadlock that occurs between Windows Error Reporting (WER) and AppLocker, “Please wait” never gives way to the desktop, nor does is there ever any opportunity to log in. The only cure is to cycle the power on the affected PC, and to hope that the problem does not recur during the next boot-up cycle.
As the preceding header snip from KB article 983551 illustrates, this code fix is currently available from Microsoft as a hotfix. This generally means several things, including Microsoft’s intentions to test the code further in the future, the need to proceed (and test) this hotfix with caution, and finally, that the hotfix is only worth applying to machines that actually manifest the problem that this hotfix addresses — namely, hanging indefinitely after the “Please wait” prompt appears on the affected machine(s).
In a related report from Softpedia this morning, however, there is apparently some good news about this problem and its fix in the offing. According to an unnamed source within Microsoft, this hotfix will be incorporated into the upcoming SP1 for Windows 7 and Windows Server 2008 R2, due to go into beta in July, and slated for public release some time later this year (exact release date is still TBD).
If any of your machines have this problem, the hotfix may help. And it seems certain that Microsoft will further test (and if necessary, elaborate upon) the hotfix for later inclusion in the forthcoming SP1 code base.
I’ve been a tremendous fan of Windows maven Mark Russinovich for over a decade now. In addition to his fabulous SysInternals utilities, he’s done more for me (and most other ordinary Windows users) to help make Windows more transparent and understandable and rather less opaque and mysterious, than just about anybody else around. Case in point: his recent blog entitled “The Case of the Random IE Crash.”
Here, he puts his detailed understanding of how the Windows debugging environment works to catch (and ultimately kill) the cause of an IE error message I’m sure far too many of us have also seen on our desktops:
This generic error message has to be one of the most vexing kind that show up, because you lose access to a running program (and one you’re probably using at the moment of failure) and can’t directly tell what’s up. Mark explains that this occurs because IE 8 runs multiple processes (one per open tab, in addition to a parent IE process) and then goes on to show you how to find the offending culprit, and start tracing symptoms back to causes. He next finds the faulting thread, then describes how to chase down unattributed DLLs to put a name on otherwise unnamed potential culprits. Ultimately, he tracks the cause back to the Yahoo Toolbar and, presumably, puts that toolbar out of the picture going forward.
His conclusion reads as follows “Using a couple of handy troubleshooting techniques, within less than five minutes I had identified the probably cause of the crash I had experienced…” I might also add that he brought a lifetime of deep knowledge and experience, and an extraordinary understanding of the MS Windows Debugger environment to the situation as well. Would that we could all do likewise!
In my most recent blog “More Interesting Windows Network Troubleshooting” I recount some recent and both interesting and vexing issues I encountered while bringing up my new HP MediaSmart Server (MSS) EX-495, which has now replaced my trusty but failed EX-475 here on the Tittel Home Network. My first round of problems, as it happens, were self-inflicted: HP warns against manually messing with drivers for the MSS but I elected to update the RealTek PCIe GBE Family Controller in the EX-495 anyway.
Bad move! Turns out this wreaked havoc on the server’s networking behavior and characteristics. Whereas with new driver I could only back up about 400 KBps from my Dell D620 notebook, with old driver that number zoomed by half an order of magnitude to something in the range of 2-2.5 MBps instead. I was also unable to complete a successful backup of my new HP notebook, though speeds were just fine.
After I explained what I had done, service agent Cathy Merrick politely but firmly insisted that I run the server recovery disk for the server, and reminded me that HP won’t support non-standard configurations anyway. With some mumbling and unhappy grumbling, I complied and was immediately impressed by the results. You wouldn’t think a driver could make that much difference but it did make a huge difference, and I was finally able to back up all my machines successfully as of last night. Automatic backup is also working properly (the main reason I bought and cherish this box is that HP makes it easy to restore any PC for which a backup set exists on the MSS, including bare-metal recovery where required) at long last.
However, I observed this morning that the server was still falling over occasionally, not crashing per se, but dropping off the network and going incommunicado. A forced reboot proved necessary to regain access to the server, where the only odd behavior I could find in the System log was an occasional Master Browser election fight with other nodes on the network. Windows Home Server (and thus also, the MSS OS) is a modified form of Windows Server 2003, and as we all know, Windows Server machines ALWAYS take precedence over Windows client OSes when it comes to assuming the master browser role. In fact, each time a workstation would contest the master browser role with the MSS, it would shortly thereafter fall over/drop off the network.
Another call to HP Tech Support, and a new trouble ticket this time. Service agent Luke Fuller had me turn off UPnP on my router, and then helped me set up port forwarding to keep external Web server access and RDP from outside my network operational. I learned some more about the user interface for my DIR-655 router, and got all this set up and working properly. I’m not sure why turning off UPnP makes such a big difference, but the MSS has been running rock-solid ever since I made that change. In searching the Web on “drops off network UPnP” I just came across lots of cases where turning off UPnP on routers makes things work (but for some, not all, users) as discussed in this vistax64.com message thread. For contrast and irony, check out this MediaSmartHome.com posting “Recommended UPnP Routers for Easy Remote Access,” where my DIR-655 appears as the third item in that list. The UPnP part works for setting up remote access all right, but unless I disabled the UPnP capability, the MSS itself wouldn’t remain available on the network.
Go figure. Just for grins here’s a screencap of my new MSS running PerfectDisk 11 to clean up some seriously fragmented data disks.
[Note added on 6/21/10: I had to return the MSS to HP over the weekend, because the unit continued to drop off the network intermittently without a definite pattern of causation, or logged errors to inform detailed diagnosis. Subsequent testing described in another blog for IT Career JumpStart explains why HP decided to label this unit “DOA,” and send me a brand-new warranty replacement. Sigh: It’s always something!]
OK, so I had to replace my trusty HP EX-475 MediaSmart Server because its network interface was stuck in beaconing mode. That is, as soon as I plugged the GbE interface for the device into a switch, the rest of the network went down because of its frantic, non-stop broadcast of DHCP Discover packets that can never be answered because that traffic never ceases. It took me a while to figure this out, because the last time I saw a similar problem on one of my networks was back in the 10Base2 days when a jabbering transceiver could — and occasionally did — bring entire networks down (which would have been in the late 1980s, to explain why it took a while to dredge that memory out of long-term storage).
In fact, it was only when I replaced my in-office 8-year-old SMC GbE switch, with a brand-new NetGear GS108, and started plugging network cables back in that I realized what I was dealing with. Plug the HP EX-475 cable in, and the network goes down; pull it back out, reset the router and back up everything comes once again. With the EX-475 out of warranty and HP no longer offering repair service, I plunked down my hard-earned cash at HPShopping.com to buy an EX-495 as a replacement, thanks to the whopping 25% Bing cashback offer that currently applies to that unit.
The replacement showed up at my door on Friday, and I got started bringing everything back up on Saturday. It took about 4 hours to get the EX-475 set up, and to load and install all the various add-ins I find useful on that box (and install ClamWin AV, 7Zip, HWMonitor, CPU-Z, and a few other odds’n’ends I can’t live without). Then I got going on re-installing the MediaSmart Server (MSS) client on my various desktop and notebook PCs so I could put the MSS to work on what I consider to be its most important job — namely, backing up my various machines on a nightly basis. Yes, indeed, the photo and media services features are nice, and the new and improved transcoding and media streaming capabilities, pretty tasty, but for me, access to a regular backup with auto-magic “bare metal” reinstall is what makes my MSS investment worthwhile.
Imagine my astonishment, when after firing off a manual backup of my traveling notebook just after lunch yesterday (it’s a 4-year-old Dell D620 notebook, which I’ve upgraded to a 7,200 RPM HDD, a T7200 CPU, and 4 GB of RAM), I found that same backup still running when I sat down at my desk this morning. After lots of fiddling around and some creative troubleshooting that included a 1-hour stint on the phone with the very helpful Froilan Batacan at the HP support desk this morning, I figured out that the problem with this particular machine comes from Windows Vista and the Broadcomm NetXtreme 57xx GbE Ethernet interface built into the D620.
How can I say this? Here are the data points I used to arrive at this conclusion:
1. I observed throughput of no more than 40-80 KBps (320-640 Kbps) coming out of the D620, using the Networking tab in Task Manager, whether I was backing up to the MSS or simply performing a network file transfer to another machine on the same switch.
2. When I switched the D620 from the GbE interface to its built-in Intel Pro 3945ABG wireless interface, throughput jumped to as high as 18 Mbps (2.25 MBps) doing backups and file transfers to other machines on the same switch.
3. When I rebooted the D620 from Windows Vista Business x86 to Windows 7 Ultimate x64, file transfer throughput jumped to as high as 50 Mbps (6.25 Mbps) doing backups and file transfers to other machines on the same switch. I just jumped into an RDP session to the MSS and saw activity in the range from 250 to 400 Mbps (31.25 to 50.0 MBps) for the D620 backup that’s currently underway to that machine running the Win7 OS at this very moment. The whole thing just completed, and took less than one hour to finish what I wasn’t able to complete in something over 18 hours running Windows Vista.
I’m not sure what’s causing this problem, and I can neither find a reliable report of anything close to similar online, nor did my friends in Dell tech support have any light to shed on this phenomenon. But if I needed another reason to run away from Windows Vista, I think I found it. And this just added considerable impetus to my need to update this machine to run Windows 7 as its primary OS (the version of Windows 7 I’m running is the 7100 beta, and that license is now expired. Sigh).
I follow Paul Thurrot’s various Windows information outlets at least weekly, if not more often than that (SuperSite, WinInfo, Windows Weekly, and so forth). This morning I came across an extremely interesting item from his reporting at the TechEd event currently underway in New Orleans. It’s from his Short Takes for the week of June 14 and runs with the title “Whither Windows 7 SP1?”
Despite earlier announcements this week at TechEd from various Microsoft noteworthies that the SP1 beta would be made available on or before the end of July, 2010, Thurrot reports that “…now this date, which was ‘GA+1,’ or one year after the general availability of Windows 7 and [Windows Server 2008]R2, is out of date.” He then goes on to say that “In fact, SP1 could be shipping a lot later than originally planned and won’t even make it in time for the end of 2010.”
That’s pretty interesting, and when taken with Microsoft’s recent “message of import” about Windows 7 SP1 — namely, that there’s no real reason to wait for SP1 to get the adoption process underway — makes the kind of crazy sense I’ve learned to grant some credence when it comes to decoding the often-ineffable work of the spinmeisters in Redmond. Not only does this help to make a virtue of a necessity, it also lets them protect their revenue projections for 2010, even if SP1 slips into the next calendar year.
Boy, will it be interesting to see how this one pans out, and whether or not beta in July translates into general availability and/or public release of the final SP1 before or after next New Year’s. Only time will tell!
Yesterday afternoon, I ran Windows Update some time after lunch to get the latest set of Patch Tuesday updates for my many and varied Windows machines. None of these boxes downloaded less than 6 updates, and some grabbed as many as 16, depending on what they were running and which applications they had installed. As Patch Tuesdays go, this one hit Windows 7 harder than most have so far, as the following snippet from the latest MS Security Bulletin will attest:
Of the seven items that touch on Windows OSes (MS10-032, MS10-033, MS10-034, MS10-035, MS10-037, MS10-040, and MS10-041) all have some impact on Windows 7, with three tagged “Critical” and four tagged “Important” as shown. As update cycles go, this one has more oomph than many have had recently, especially for Windows 7. That siad, much of what’s involved relates more to legacy code included in Windows 7 for backward compatibility and interoperability than to actual core components of Windows 7 itself.
You’ll also find updates to the Windows Malicious Software Removal Tool, the Windows Mail Junk E-mail Filter, service packs for .NET Framework 3.5 (SP1) and .NET Framework 2.0 (SP2), a new root certificates update, and a cumulative roll-up for IE 8 in this month’s offerings as well. These come along with compatibility list updates for IE 8, and some revised daylight savings time and time zone changes for various countries, too.
In short, there’s a lot going on for this month’s Patch Tuesday, some of which cries out for rapid analysis and deployment for Windows 7 installations.
On June 7 at TechEd in New Orleans, Microsoft went public with an announcement that a beta version of the Service Pack 1 for Windows 7 and Windows Server 2008 R2 will be available “…by the end of July” (read more about this in Gavriella Shuster’s June 7 blog). She also has this to say about SP1 and Windows 7 as well “…SP1 will not contain any new features that are specific to Windows 7 itself. For Windows 7, SP1 will simply be the combination of updates already available through Windows Update and additional hotfixes based on feedback by our customers and partners” (the italics are mine, but the words are hers, and boy would I love to know what those items might include).
Microsoft is banging the drum hard and loud to get people to adopt Windows 7 sooner rather than later, leaning in part on these words to convince prospective adopters that because SP1 really won’t include any substantial changes in capability, functionality or (presumably) stability, there’s no reason no to act now. Of course, enterprise adoption cycles being what they are (slow, complex, and as much politicially and financially as technically driven) I’m not really sure this will make much of a difference.
All that said, I’m still dying to lay hands on the beta, and hope to find more information about what will be included with SP1 as soon as I can. Count on me to keep you posted as I learn more.
When I got up on Monday morning, Memorial Day, my wife Dina let me know she couldn’t access the Internet. “No big deal” I thought to myself: “Either I’ll reset the cable modem or the router and all will be well.” Not only was that wrong, wrong, wrong, but unbeknownst to me, I was about to embark on a network troubleshooting adventure of epic proportions. In fact, this adventure is still underway, and will continue later this morning, when Daryl Giles of Austin Advance Technology shows up with his cable testing gear and some replacement parts ranging from in-wall Cat 6 UTP cable to new swap-ins for my punchdown block and network interface patch panel. Sigh.
I did the easy stuff right away — reset the cable modem and the router — and fully expected my problems to be resolved. Not so. “Great!” I figured: “Let’s see what’s up with the network clients.” A quick look at the network status on my primary desktop showed that the network interface was trying to use an APIPA (Automatic Private Internet Protocol Addressing) IPv4 address, which from long experience I know means that the client can’t access a DHCP server. That server runs on the router, so my first thought was that the router had gone south. Jump in the car, drive to Fry’s (thank goodness we have one within 15 miles of my house — where else can you buy an 802.11n/router/firewall box on Memorial Day?), pick up a replacement router, drive back home.
After bringing up a new router, I *still* couldn’t get a DHCP address from the router. My next thought was: “Drat! The cable modem has failed.” Nothing I could do to fix my problem until early the next morning when I could visit my nearby Time Warner service office (just over 3 miles from my house) and swap out my 4-year-old Scientific Atlanta WebSTAR for the now-Cisco-branded 2203C cable modem with phone jack that has replaced the older unit in the interim. After taking the box home, and spending some time on the phone with Time Warner tech support to get everything properly provisioned and working correctly, I was forcibly struck with the realization that some element within my in-home cabling was causing the problem.
Here’s how I finally figured this out: To follow the installation instructions for the router, I had to haul a notebook PC into the master bedroom closet where our wiring center is installed, then cable the PC directly up to the cable modem to launch the router install software (It requires an active connection to the Internet to work properly). I simply ran a 1.5m RJ-45 Cat6 cable from the router to the notebook to do this (you can’t use wireless until the wireless network is setup and configured, of course). This worked fine, after I used the netsh winsock reset command to clear out the detritus of the APIPA setting and restarted the notebook so those changes would take. I happily spent the next 20 minutes or so getting the wired and wireless sides of my home network reconfigured, fully convinced that my troubles were over. No joy!
On the other end of my in-wall wiring, none of the machines attached to the RJ-45 wall plates could access the router to obtain a DHCP address, so they were effectively knocked off the wireless network. I switched some key machines (an HP notebook that Dina is now using for her regular daily computing tasks, and my primary desktop which has an Airlink 101 USB Wireless N 150 network interface filling in for the usual GbE RealTek PCI interface I normally use for network access on that machine) over to wireless so I could get back to work, and called a network consulting company to bring in a cabling technician to check out my home wiring plant.
Right now, I am also using a 100 foot Cat5e cable to hook up my other notebook — my traveling machine, a Dell D620 that’s still running Vista Business because I haven’t gone through the uninstall/reinstall process to move Adobe Premiere from that machine to the newer HP notebook that Dina is using right now. I can’t establish a DHCP connection from scratch using that cable (GbE at 350MHz won’t work beyond 80 feet or so), but because I simply unhooked the 1.5m cable from the Dell while it was in my closet, then attached the hundred footer to its RJ45 port, it can use the DHCP address it already has assigned. Ironically, this machine is 802.11g only, and I don’t want to sacrifice bandwidth by running the router in dual-band mode, so it’s the only machine that currently has full-speed Internet access in the house.
I have to believe that because the punchdown block and network patch panel are the only network components in common among the 4 RJ-45 wallplates in the house, none of which will now resolve DHCP, that the problem has to lie somewhere inside or between those devices. When Daryl gets here later this morning, we’ll figure it out. It’s enough to make a guy like me think more seriously about plopping down the $1K or so it would cost to buy a Fluke Ethernet cable tester. I know it’s got to be an attenuation problem somewhere along the way, but until we can check all the cables and connections (including the patch panel and punchdown block) there’s just no way to figure out what has to be fixed or replaced to get things working again. What I can’t understand is why it just popped up out of nowhere, 4 years after I installed this network which had worked flawlessly until Monday morning, without positing a failure of some kind in one of those components. The cable guy thinks it’s a lightning-induced problem (we had a major thunderstorm on Sunday night) and the networking guy thinks it’s bad cabling. I want to find out for sure what it is, and fix it!
I’ll follow up — hopefully, tomorrow — to report on what we learn and how we fix my situation. Stay tuned!
If you read this blog, you know I not only think highly of the various Secunia software monitoring products available — I use Secunia Personal Software Inspector (PSI) for my personal machines, and recommend the Secunia Corporate Software Inspector (CSI) for workplace use — I also use and work with them at least weekly. That’s how often I auto-scan my HP server, and the four desktops and four notebook PCs I have at my disposal right now.
This morning, when I ran my weekly scan, Secunia informed me that the Java Runtime Environment 6.15… was now out of date, so I went off to download the latest version. Out of habit I used Revo Uninstaller to remove the JRE from my machines knowing that manual uninstall is required to get old versions of Java out of the way so that new ones can be installed in a pristine setting. Out of habit I reached for my favorite uninstaller, Revo Uninstaller. It worked fine on my 32-bit Windows 7 systems, but I hit a snag on my 64-bit systems (Revo Uninstaller does not provide access to the 64-bit JRE, though it is happy to work with the 32-bit version on either 64- or 32-bit systems).
I did a hurry-up manual uninstall (removed the Java direcotory in the Program Files directory, and a quick purge of Java related Registry settings). But when I downloaded and installed a new 6.20… JRE, though the 32-bit version installed without a hitch, the 64-bit version threw error 1327 “Unable to find a necessary DLL.” After trying a restore point and researching various possible fixes on the Internet (of which there are plenty, but alas none of which worked for me), I took advantage of my nightly backup to restore the Java directory I’d trashed as part of my hurry-up manual uninstall manuevers, then tried to install the new 64-bit JRE 6.20… This time, I was successful, to my great relief.
It reminds me that you have to make sure your tools are 64-bit savvy when working on 64-bit systems. As a little additional investigation showed me quickly and directly, had I simply chosen to use the Programs and Features item in Control Panel to extirpate the original 6.15… JRE, I would have been able to install the 6.20… version without difficulty. That’s why it’s always important to remember what you’re doing, and what tools you’re working with when adding or removing software from a Windows machine. Hopefully, you can learn from this (minor) foul-up on my part!