Windows 10: Setup/upgrade failure - why no monitor to pinpoint causes?

Windows 10 probably has had more installations during it's first year of life than any other Windows version before, due in part to the continuing Insider Program and also due to the free year of upgrades that has just ended. It is likely that there will be a publicly regularly available set of new build releases for the foreseeable future if Microsoft continues to value the Program.

Microsoft Windows developers have clearly modified and improved the Setup process during this time, and no doubt there will be even more advances to come. Like so many Windows-related systems, Windows Setup is mostly undocumented, part of the "Security by Obfuscation" mindset that tries to keep hackers out of Microsoft products.

Yet there are still seeing installation and upgrade failures, often without any reasonable explanation why a particular attempt has failed, although thankfully the "something happened" error message is not as common as it formerly was!

Underlying the process of upgrade and setup there are certain logs that should and may be able to shed light on failures, but seemingly these rarely offer useful pointers to the failure circumstances.

The best advice given to people with setup or upgrade difficulties seems to be to run the system with as few peripheral devices attached as practicable for clean installs, and with no third party, or startup software, including firewall and antivirus protection, and no networking for the setup run, in case of some possible conflicts.

There seems to be little indication of any Windows Error Reporting activity, or any "crashlog" or memory dump saved if Windows manages to rollback to the previous installation, or worse, fails to roll back to a useable system.

WinPE (more than one version apparently, with either a Vista/Windows 7 or a Windows 10 windows appearance, at different times during Setup) is the basis of the setup process, and may be observed in action throughout most of the setup process, by opening a cmd console using <Shift>+<F10> keys pressed simultaneously.

There is limited Windows functionality under WinPE - taskmgr.exe, notepad.exe, regedit.exe, and maybe a few other basic Windows programs are available in GUI mode, with many of the commandline utilities such as diskpart.exe, dism.exe etc., are all usable when run from the commandline.

Explorer is not available.

If the mouse is functional, depending on the basic drivers that are loaded, then it may be possible to use a pointer in the GUI utilities, and one of the features of Task Manager is to run new tasks, so it is possible to browse through the drives and run portable applications, such as the 7-Zip File Manager in order to explore the file activity going on during setup.

Using Task Manager, one feature with many setup failures is that the CPU utilisation is running flat out at 100%, perhaps an indication of a driver or resource management problem - commonly with the system interrupts (deferred procedure calls) running at a high level above 80% of CPU use. The other downside is that the processor may overheat under these circumstances, and if this does not lead to a system burnout failure, or a failure-preventive shutdown, of course, this leads to the setup program crawling along, fighting for processor time segments. Eventually, some process may trigger a timeout, and the setup bails out.

How can we find which devices are responsible for this misbehaving? All the user sees is the ring of dots and "Getting Ready" or some such non-informative message onscreen for perhaps hours.

MSInfo32 can be called from the command line, but of course will be subject to the same lack of processor availability as setup, and the WMI service will not be available - so to all intents and purposes, is useless.

I feel it is high time Microsoft or some 3rd-party developer should produce a monitor for Windows Setup to indicate whether all is progressing fine, or that there is some problem that either can be fixed with the application of a driver or patch to fix the problem, and that there should be more WER involvement with Windows Setup.

In this case, at least, some more information is needed to be made available to improve the situation.

:)

 

Windows 10 setup logs deciphering

Where can I find an explanation regarding the contents of the setup log, i.e. what is "MOUPG", "CSystemHelper",etc.? How can these entries be correlated to pinpoint a particular failure? Leaning about the setup and error logs can help me understand why
I can't upgrade my PC from Win 7 pro to Win 10. Thanks in advance for your response.

 

On Dual monitor setup, mouse clicks don't register on main display.

Hi! I have a dual monitor setup with my main screen extended to my second monitor. A month or so ago I discovered that on my main monitor my mouse clicks do not always register. They fail 80% of the time. Sometimes it occurs as links just won't click or
the scroll bar won't move. It doesn't always happen and the failure can happen within seconds of a success. Occasionally if I just move the cursor I can get it to click but I mostly just move the window to my extended (or second) monitor and everything works
perfectly.

I have tried changing the screen resolution and refresh rate but that has not helped or made any difference. The only other interesting piece of information is that this failure only occurs on the main monitor. If I change monitor 1 from main to extended
the failure happens on monitor 2, the new main monitor. If monitor 1 is the main, the failure only occurs there.

I have no other ideas on how to fix this since it seems to be a software and not a hardware issue.

 

Agree wholeheartedly Fafhrd, especially the error message "Something happened" well duhhh, we can see that. It's almost comical the way it puts up that error message with no other verbiage about what caused it, and what a user could do to resolve the problem. Of course it's never funny if it happens to you.

Most are advised to not run any 3rd party software during install.

If MS would create an application to run during install, it could monitor the install and if "something happened" it could report what exactly caused the failure. Not in some cryptic, undecipherable error code, but in plain language.

Did a driver fail, is a patch needed, does a piece of hardware not support the OS? It would be far easier to resolve a failed installation with some useable information about the reason for the failure. A program created by MS would be designed to run during install without affecting anything, after all if they wrote the OS, they should be able to write some type of an install monitor for their OS.