Share your experiences with "in-place upgrade" OS repair technique

[BonzaiDuck]

Some sources like Maximum PC Magazine recommend reinstalling your OS (typically Windows) annually. The advice sounds like what you'd give to someone who mostly "plays" with computers, or who has all the time in the world to sort out the changes and the work.

For OS installations with corrupted files -- or simply situations where it seems prudent to refresh the OS -- there is a Windows "upgrade" feature that allows for an OS refresh without having to reinstall drivers, software and the other pesky little details that could take you days to complete -- even with careful planning.

However, the wisdom in "guides" for the "in-place upgrade" repair suggests that "certain customizations" you had gradually implemented with your use of the original OS installation would need to be "re-configured" or tweaked.

What sort of "customizations?" What sort of driver installations would need to be repeated? Not that you would expect anyone to have done so, but it would be a good idea to develop an inventory of likely "adjustments" you'd need to make if you take such a step just slightly less drastic than a complete re-format/re-install of OS and about everything else besides your data.

Are there any ideas? Experiences? Thoughts about developing such an inventory? Or are the items of such a small number that it wouldn't seem worth the trouble?

It is always a good idea to know as much as possible about the details before one proceeds with such a project: you're more likely to "get it right the first time" if you know what to expect in the actual "doing" of an "in-place upgrade repair."

 

[Bubbaleone]

I've been successfully using the in-place upgrade procedure, for several years, to repair misbehaving installations of Vista and 7. I have several previous posts on the topic (with links) in these forums. I'm not an 8.0/8.1 admirer, so I won't go into the convoluted and arcane (IMHO) procedures that Microsoft decided to implement in order to manually perform an in-place upgrade (repair) on those systems. An in-place upgrade is much quicker than performing a clean installation and for this reason I've found it an excellent solution for curing problems that used to take hours to diagnose, trace down, and manually repair. There are times when a clean installation is the only logical solution but I'm now performing that procedure only about one-fifth as often as I did before I began regularly utilizing the in-place upgrade. An in-place upgrade won''t work if you can't boot to the desktop, and it won't work in safe mode.

Here are a some things to be aware of that I've learned will ensure success;

First delete all temp and recycle bin files then run chkdsk (from an elevated command prompt) on the volume, with these switches:

chkdsk C: /x /v /r /b

When chkdsk completes and you're logged back into the desktop, insert the flash drive or DVD containing a Windows image of the same bitness and service pack version as the system you're repairing, then begin the procedure (You can also edit the ei.cfg file and then save the ISO image which gives you an installation media that allows you to select any version from Starter to Ultimate). The time required to complete the procedure will depend mainly on how many third-party programs are installed, the amount of personal files e.g; docs, pics, music, videos, etc. and how fast (or slow) the hardware is. Regardless, an in-place upgrade is much quicker than a clean installation by virtue of the fact that all programs and personal data are ready to roll when the procedure completes.

There is one caveat; as in a clean installation, all Windows updates are deleted and have to be reinstalled. Early on I discovered that using the excellent Windows Updates Downloader software can save hours compared to using regular Windows Update.

 

[Mushkins]

I haven't annually reinstalled windows since XP was the latest and greatest OS. Vista and forward simply don't need it done anymore.

I also shy away from in-place upgrades and repair installations to fix windows problems, as I consider a system that needs one to be done unstable and untrustworthy. I'd rather take the time to reimage now than have a user complain that their machine is acting funny/down again a few days later. An in-place repair is a last resort for when I do not have the resources available to quickly swap or reimage a machine (remote offices, emergency situations, etc).

But that's just my take on it.

 

[Bubbaleone]

Mushkins, I completely agree with you that reimaging is the single best solution when time and a known correct image is critical. My comments are directed towards users that may not be well versed in imaging techniques, but who do have an installation disk, need to get their system fixed, aren't looking forward to having to reinstall all their third-party programs, and then restoring their saved (hopefully) personal data following a clean installation.

Over the course of years I've compared, side by side, many systems that received an in-place upgrade versus a clean installation on the same or very similar hardware, and in my experience there's no discernable difference in system functionality, stability, or longevity between the two procedures.

 

[escrow4]

It takes less than 15min to install 8.1 on this 1TB SSD, less than 15min to install and configure the dozen or so programs I use, and less than 10min to copy across core data. I have no idea why it takes people hours - do they all install a hundred programs they never use?

 

[Bubbaleone]

It takes less than 15min to install 8.1 on this 1TB SSD, less than 15min to install and configure the dozen or so programs I use, and less than 10min to copy across core data. I have no idea why it takes people hours - do they all install a hundred programs they never use?

The machine in my sig is comparable in installation times so, without doubt, I know today's hardware is so smokin' fast it pretty much negates many of the reasons one might even contemplate an in-place upgrade repair procedure in the first place.

On the other hand, there is a large percentage of computer users who don't run state-of-the-art hardware and who have accumulated a large number of third-party programs over time. An in-place upgrade repair can be a viable alternative for many of these users.
.

 

[BonzaiDuck]

The machine in my sig is comparable in installation times so, without doubt, I know today's hardware is so smokin' fast it pretty much negates many of the reasons one might even contemplate an in-place upgrade repair procedure in the first place.

On the other hand, there is a large percentage of computer users who don't run state-of-the-art hardware and who have accumulated a large number of third-party programs over time. An in-place upgrade repair can be a viable alternative for many of these users.
.

That's an interesting point. My software acquisitions include disc-media -- retail or OEM -- with the product key or license on the envelope, or downloads with e-mailed licenses which I copy to notepad and save with the zip or exe file. But the folder where I save all that stuff eventually accumulates (a) prior versions and (b) either items I never installed or chose not to keep -- usually freeware/shareware.

For those impressed by the speed of fresh-installs of either Win 7 or Win 8, you need an inventory, list and sequence of driver installs; you need the drivers "available."

Then, there's the strategy you adopted for software when you began using (or finished building) the machine. Think of the difference between an FA-22 Raptor and the Starship Enterprise-next-generation. I chose the approach of a computer that "did everything." I have plenty of computers, and I might have spread around the software, but -- just as much trouble to keep track of it. It's even an annoyance under such a scenario to flip the KVM switch back and forth, possibly even bring a machine out of sleep.

If I had to do a fresh install, I'd follow this plan: Open Ctrl-pnl->progs & features; inventory all the installed software; note the version and install date. Then open my folder of downloaded programs; select those that match the first list; move them to a thumb drive or similar. And -- ditto with the drivers. Gather SW install disks; install drivers, SW on discs and SW downloads.

I'm not even sure I need to do the "upgrade repair." I'm just thinking I might want to. I've traced down and killed just about every red-bang and yellow-bang error or warning in my event logs, with one or two specific to software (NUANCE) -- with forums for the software showing "no resolution" through the present.

Then, there are my results with "SFC /SCANNOW." It reports "some file corruption" but unable to repair all. I looked at the CBS log: it all seemed related to CAB files from Windows updates that had been cleaned out by CCleaner or similar. I can run CHKDSK with additional parameters, but the runs I've had including the "bad sector" scan don't seem to report anything damaged or repaired.

If I've had any "instability," only a little of it may have involved "insufficient voltage" and a lot of it was either misbehaving drivers, misbehaving bloatware or AV/Firewall restrictions on software modules which should have been "Trusted" from the git-go.

Take for instance another discovery I made about NVidia driver and bloatware upgrades. There is a service it installs called "NVStreamSvc." Folks at the NV forums were complaining even in recent months that this gets installed before you know and regardless of your need for it: It is intended for the "SHIELD" hardware you can get for gaming. The skinny on the street suggests that it causes problems -- perhaps more so -- if you don't have "SHIELD." It evidences a common "instability" or malfunction -- prompting folks to disable it completely.

With all my event logs showing nothing but blue or "benign", I'm proceeding cautiously on this, planning to get my OS off its HDD and replace the latter with an SSD. It probably behooves me to assure myself of a near-perfect OS deployment, so -- I've begun to entertain this "upgrade repair" option.

StarShip Enterprise will be a b**** to rebuild from scratch. Don' wanna do it, neither-nyther.

 

[Essence_of_War]

Take for instance another discovery I made about NVidia driver and bloatware upgrades. There is a service it installs called "NVStreamSvc." Folks at the NV forums were complaining even in recent months that this gets installed before you know and regardless of your need for it: It is intended for the "SHIELD" hardware you can get for gaming. The skinny on the street suggests that it causes problems -- perhaps more so -- if you don't have "SHIELD." It evidences a common "instability" or malfunction -- prompting folks to disable it completely.

Heh, I ran into this about two weeks ago.

My work desktop has an old Nvidia 9500, and I don't game or anything on it. After a driver update, NVStreamSVC starting eating all CPU cycles, and would immediately resume eating all CPU cycles on reboot until I finally uninstalled it.

After having had unpleasant experiences w/ AMD/Radeon driver updates, I was mentally swearing to myself that my next GPU would be from Nvidia, but after this experience with their little power-virus, I'm not so sure.

 

[BonzaiDuck]

Heh, I ran into this about two weeks ago.

My work desktop has an old Nvidia 9500, and I don't game or anything on it. After a driver update, NVStreamSVC starting eating all CPU cycles, and would immediately resume eating all CPU cycles on reboot until I finally uninstalled it.

After having had unpleasant experiences w/ AMD/Radeon driver updates, I was mentally swearing to myself that my next GPU would be from Nvidia, but after this experience with their little power-virus, I'm not so sure.

That sounds much like some had reported it. They had instability during game-play; one guy was "troubleshooting" his system and came across it; others reported filling up RAM and CPU cycles. Me -- I'd found that Kaspersky had "restricted" parts of my SiliconDust software modules, and of course -- NVStreamSVC right along with it. I'm trying to remember exactly when they began to release driver updates with "Stream" -- it could've been a couple years ago. After sorting this stuff out and cleaning up sources of Event Log entries, I'm beginning to wonder . . .

As I've said, if I'm going to migrate to a Sammy 840, change from RAID to AHCI, and avoid OS and software re-installs, I want to know exactly WHAT I NEED to do without unnecessary misery.

Bubbaleone gets my biggest thumbs-up on this business so far. Very helpful. I'm just wondering what I'll have to do to tweak Media Center back to life. But the "upgrade repair" is supposed to leave "software" intact. "Personalization?" That could mean a lot of minor stuff, and then -- maybe not so minor. I guess the point (continues . . ) -- I'm not yet sure about the "NEED."

Fact is -- one could spend a lot more time trying to assess "need" than one might spend just going forward with it. Any troubles that I THINK I have, don't suggest "last resort" scenario for the upgrade-repair. Then again . . .

After three years, maybe it's just a good idea . . .

 

[BonzaiDuck]

.. . . .

Over the course of years I've compared, side by side, many systems that received an in-place upgrade versus a clean installation on the same or very similar hardware, and in my experience there's no discernable difference in system functionality, stability, or longevity between the two procedures.

Very good to know this. You are very credible when you say "over the course of years . . ." and " . . in my experience."

:thumbsup:

 

[BonzaiDuck]

I'm going to post this here, and hope nobody loses patience with me.

One reason to consider "In Place" or "Upgrade" repair is "corruption of OS files." You determine this by running SFC /SCANNOW in an elevated command prompt -- I believe it is called -- but "administrator" status would assure it.

For me, this results in the frustrating message:

Windows Resource Protection found corrupt files but was unable to fix them.

Running CHKDSK as a scheduled reboot step, no problems are found except in inconsistency of some security descriptors. I am thinking this also provokes an Event Log warning about certain handles that are not being released, which would be closed at the time a restart is initiated.

I went through this juggling act over my server account access from this workstation, changing my logon account ID. I'm wondering if other "accounts" related to software installation also have some bug of omission. The MS advice -- TechNet, forums, knowledge base only address this problem as "These programs should be investigated further."

Now -- pertaining to the CBS.log file of SFC /SCANNOW results. I can then run COMMAND as an administrator and execute the following command and parameters:

findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt

Just about every entry I find in this results analysis looks encouraging:

[date][time], Info CSI [8-place hex-code] [SR] Verifying 100 (0x0x0000000000000064) components
[date][time], Info CSI [8-place hex-code] [SR] Verify complete

in the two-event pattern.

The only thing I've ever found -- and I've been checking this and thinking of it for a month or more:

[date][time], Info CSI[hex-code] [SR] Cannot repair member file [1:18{1:18{9}] "mfc80.dll" of Microsoft.VC80.MFC, Version = 8.0.50727.762, pA= PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral, PublicKeyToken = {1:8b:1fc8b3b9a1e18e3b}, Type = [1:10{5}] "win32", TypeName neutral, PublicKey neutral in the store, file is missing

[my italics] This in turn is likely a component of C++ Redistributable (x86) 2005. I think I had identified the version, and there are other versions of the 2005 redistributable -- likely installed by other software -- or by me when I first attempted to "rectify" this very message of SFC results.

It is quite possible that I uninstalled the offending software long ago. It is quite possible also that it could be linked to the "personal" version of the UPS connection and monitoring software for my CyberPower UPS, as the filename is the same I'd discovered in the [wrong place] of my user account file. I know I either uninstalled it, or expected the "Business" version of the software to remove it properly. But I can only confirm a coincidence of .DLL file reference.

So quite possibly, SFC is only turning up a missing version of an old redistributable DLL file which it doesn't need (since there are likely two or more later versions properly installed), and my software doesn't malfunction.

If I've ever had instability, it coincides with Media Center, LiveTV with SiliconDust HDHmrnPrime and Hauppauge HVR-2250. It never occurred when 2250 was being accessed for OTA broadcast. And as I said, ,I discovered this Kaspersky restriction on Silly-dust when it inhibits communication in at least one direction to manage broadcast transmission, re-establish a "reservation" for DHCP-managed IP address for the triple-tuner device. It would occur between once weekly and sometimes an interval of a month.

Again, I emphasize on my own intense focus on this at the moment, that it really makes sense to take action assuring that the cloning of the boot-system disk to an SSD has as perfect a source as possible. If acceptably "imperfect" includes my own benign (hopefully) interpretation of the missing DLL file, then there might be little reason for an "UPgrade-Repair."

then again -- why not?

Any useful thoughts about this would generate effusive appreciation from me. But everything on the system seems just great right now. I'm beginning to think I SHOULD do it -- just to assure a great transition to the SSD boot drive. But these results and my continued efforts to make "corrections" -- also make me hesitate. . .

 

[BonzaiDuck]

Here's some more, from the event log report of chkdsk. The routine of it shows 0 bad file records processed . . . 60 reparse records processed, Index verification complete, 0 unindexed files recovered. (and 0 scanned)

Then "Index $SII of file 9 contains 25 unused index entries" repeated identically for "Index $SDH."

"windows has checked the file system and found no problems."

the remainder shows the usual statistics for files, indexes, "0 KB in bad sectors." KB in logfile, NNNNNNNNN KB available on disk . . allocation unit size of 4096 . . .

 

[BonzaiDuck]

Some advice on this topic at PC World suggested an upgrade-repair would take 40 minutes. Mine took all afternoon. I don't want to think of what an install-from-scratch-plus-software would be like. . .

If you run ASUS Suite II or III, you're better off uninstalling it before you begin the upgrade-repair.

Then, there's the 150 Windows Updates still short of all those needed, so figure on two or more passes.

I've yet to look at the event logs. I'm suspecting that the clean blue logs of my pre-upgrade-repair installation have been replaced by more puzzles of indications.

Otherwise -- not too bad. I'll probably be fiddling with settings and corrections for the good part of a week.

 

[BonzaiDuck]

Everyone's situation with this will vary widely. It depends on whether or not your OS installation is "really" corrupted -- for one thing. I could almost say that glitches you find after the upgrade-repair might be indicative of problems and solutions for them on a pre-upgrade-repair clone or existing system disk.

In the process of returning to the original installation disk which I attempted to "repair," I discovered software installation causes for a missing C++ redistributable component that led me to the upgrade-repair in the first place. I also discovered the same problem source that had caused "Side-by-Side" errors in the event logs occurring every 24 hours.

The "upgrade-repair" could be considered "successful" for a system in more trouble than my own, and a Mainstreamer looking at my original OS installation might think "nothing wrong, so why worry about it?"

The upgrade-repair offered up all sorts of errors and warnings in the event log that I had previously resolved. So now, I've gone back to the original OS disk, and continue to tweak it so that my event logs are all "blue."

Next, I'm going to clone this disk to a Sammy SSD.