Thankyou Shaon for your continued attention and help.

I had ignorantly presumed the MCTool was in effect a download manager which downloaded/checked the entire ISO rather than 'constructed' it. Your advice that it is not possible to gain a common checksum of any ISO created by the tool obviously answers my primary question.

Yet the intent behind that initial question was to gain an understanding of how I can verify the integrity of the install media, downloaded using official MS method, which I intend to use as the basis for building the winOS. In this respect I am hardly any closer to my goal of being able to verify/trust the media to perform a "clean install".

I mean "clean" in both senses of the word. The concept of SISO pre-dates Microsoft. The fact that the ISO doesn't contain enough s##t to stop it booting, or even setting up an OS, does not prove that the ISO or the OS constructed from it does not in fact contain s##t which might unduly complicate processes down the line.

My enquiry is not merely an academic one.

I have been asked to fix an Acer laptop for a boy who for a few short months proudly enjoyed his new rig. The laptop came with win 8.0 pre-installed and all the devices worked as expected. He was a good boy and followed recommended procedure by allowing automatic updates.

MS effectively coerced this kid into "upgrading" to build 9600 when they unexpectedly removed support for full updates on the breed of OS he was using. MS deceived him into readily accepting the installation of "windows 8.1 update 1" by strongly implying that it was, well... you can read, merely an "update" - not even big enough for an 8.2 moniker.

"Win 9" broke the kid's heart. He was suddenly the kid with the gimpy computer - no webcam, a wild trackpad and a schizophrenic network connection. Whilst still under warranty, Acer performed their magic and "clean installed" build 9600, leaving the win8.0 recovery and original 'push button' partitions in place. This gave the boy an impressive 6 partitions but didn't actually fix any of his problems.

Acer then abandoned this kid by gutlessly feeding him 'professional scareware', blaming all his woes on malware. The frustrated boy, aided by well-meaning friends, over-reacted to this supposed threat and further trashed his system {as indication - a year later I found it running two active AVs along with services for an extra two}.

Laughed at by his macbook using brother, the boy abandoned his MicroSelfish rig.

The pity about this whole saga is that even when half-broken Win 9 looks like it's actually a decent OS. If only it could simply be instructed to play nicely with devices.

I have found countless sad accounts of systems which, after 'updating' to build 9600, have exhibited strikingly similar problems to those which exist on the machine I am working with.

I find it interesting to note that there are comparatively few accounts of troubles after a "clean install". It isn't clear to me whether this is a result of people having abandoned their machines like the kid did or whether they simply reverted back to builds 9200 or 9400 {"stuff the updates"}.

I suspect lots of people paid 'Danegeld' for either a new build 9600 install disk or a magic fix from a professional who had such a disk and performed a clean install.

I also suspect there were many who couldn't afford to pay and were subsequently {and ironically} encouraged by MS's actions to download the media from 'unofficial' sources. I now wonder if I should attempt to do the same - at least I could easily verify the media with an officially published checksum and move on.

Microsoft eventually provided a tool which {it is claimed} can be used to facilitate a "clean install" of build 9600. I have used this official tool to download the setup media.

I do not have the option of reverting back to the originally installed {and no longer supported} 'build 9200'. Those partitions were damaged. The existing build 9600 was also badly damaged.

I have tested {OS independent} the major hardware components and am convinced the problems are all software related. I feel that doing a clean install of the OS and replacing a couple of wonky drivers would go a very long way towards resolving all issues.

I anticipate that finding and testing the correct drivers may be a time consuming task yet the process should nonetheless be relatively straightforward.

I want to use "known good" media to establish a "known good" baseline for the OS before applying updates, drivers, and {lastly} other software. I am astounded that the seemingly simple task of verifying I am starting this process with "known good" media with "known good" content has be so difficult.

I wonder why MS insists on a "near enough is good enough"/"suck it and see"/"cross your fingers"/"have some faith" approach by it's customers. Does MS management operate this way?

I am not encouraged by either the process or the behaviours of the MS supplied MCTool. The first ISO it 'constructed' for me will not even boot. I have twice burned it to dvd and tested. The MCTool gave me no indication whatsoever that it had failed to construct the ISO correctly.

The second ISO it constructed for me does boot up and does install an OS. I have now used that install media multiple times to build the OS foundation. All installations have been unexpectedly problematic. To put this into context, I *did* expect there to be problems with the operation of some devices.

When allowed, the OS self-activates using the BIOS-embedded key.

I have tried to inject 3rd party drivers before MS OOB ones. This did not fix any issues. It may simply be that I need to keep searching for the "correct" drivers {there appears to be a bewildering amount of choices}.

Looking through WUC I have gained the impression that MS has now taken the lead in providing hardware drivers {esp. when compared to the embarrassing filth which Acer calls "Support"}. So I decided to trust in the fully automated MS update process to see if these updates can eventually lead to MS supplied drivers which *actually* work.

Frustratingly, most of the updates "failed". I have tried to apply these updates with and without Defender running. I have repeatedly used the MS 'fixit' tool which keeps telling me it has found and "fixed" problems. Very ugly.

I now wonder how I might, with a straight face, eventually advise the boy to keep his "win9" OS fully updated using the officially recommended method.

The machine is not ancient - manufactured in mid-2013.

Basic OOB MS drivers for webcam and touchpad work. Whilst I have not yet extensively searched for alternatives drivers for these devices, the OEM supplied drivers and software I have tried break them again. It may be that basic drivers will be the best that computer geeks can offer the boy and that he will have to find other uses for his multi-finger gestures.

Regarding the frequent network dropouts I have searched for and {conservatively} applied a variety of "fixes" for alarmingly similar problems which I have found splashed all over the internet. I have used things like ipconfig/netsh commands, changing DNS, switching off power management for the network devices, etc. None have lasting effect.

Throughout, I have tried to avoid introducing any major 3rd party software which might complicate investigations yet I was forced to install an alternate browser after IE {which I haven't used since IE3} absolutely refused to save web pages in any format {incl. text}. Apart from suffering the same network connection issues, the alternate browser appears to work just fine.

This is 2015. "Win8.1 update 1" was introduced a reasonably long time ago. I am sick to death of having to do all this monkeying around to properly install MS's current OS and have it play nicely with the devices on the underlying machine.

I am especially peeved that I don't even know if any of the issues I face whilst trying to resolve the matter simply stem from flawed files on the install media. Even on the damaged OS I originally found on the machine IE and auto updates worked fine.

This is fundamentally an issue of 'trust'.

At this stage of the game the peaceful win7 on my desktop machine will *never* be ugraded to another Microsoft OS. I would also throw this POS Acer/win9 away if I could also gutlessly ignore the boy who has already been shafted by big men in suits.

So I seek your further help, on behalf of the boy.

I do *not* here and now seek help with all the problems which exist on the machine. I particularly seek help regarding how to verify the integrity of the media used to install the OS.

I have no idea how the size of "install.esd" relates to determining the integrity of the hundreds of other files which also populate the ISO. Nonetheless I checked this within both ISOs I received {one now "known bad"} and both matched yours for size. This method appears to prove nothing.

I don't seek clarity about the above process and will simply presume it was worth a try anyway. It did however lead me to another line of enquiry which may prove useful {Yet may prove to be wishful thinking founded on ignorance}.

Rather than comparing filesize, wouldn't it have been more exact to compare checksums for the file? Further, couldn't this entire issue of verification be solved by extracting all the files from their ISO container, checksumming the resulting individual files, then comparing checksums?

{as a random example, I presume that "/boot/resources/bootres.dll" *is* v6.3.9600.16384 *is* "17.8KB" in size *is* datestamped "Thursday, 22 August 2013, 10:39:14 PM" *is* sha1 "3e8c4c5dcc9797f596dcca7334f405b217242190" -- every day of the week, everywhere in the world., within any of the same 'type' of ISOs created by MCTool.}

Although the above method is more cumbersome than simply comparing the checksum for one file {ie the ISO} it would still be a relatively simple thing to do programmatically with regularly available tools - 7-zip/ISObuster etc to extract the files, any of a number of tools/methods to gain an ordered list of checksums plus a tool capable of showing differences between two lists of checksums {eg. winmerge}.

By doing a simple comparison, any individual with an MS supplied ISO/disk could essentially verify the integrity of the contents {ie the parts if not the whole}. Obviously, this would involve having a reliable list to compare against.

I suppose MS could officially provide this data, even in a simple text file. Do you know if they have? {I can't see one within the ISO itself which would seem to be a logical place for it}.

If MS has not provided this data then perhaps the MS community could independently establish such lists. It wouldn't take very many comparisons before a reliable list could be published. Perhaps such lists already exist?

At a pinch, it seems to be that any two customers possessing what is ostensibly the same ISO to produced the same type of OS might alone be able to establish confidence in the *contents* of their ISOs if they compared the checksums of the extracted files and they exactly matched.

Obviously, if the checksums of any of the compared files do not match then the data set is too small to establish which copy of a non-matching file, if either, is true.

Is the above reasoning and strategy sound?

Otherwise is there an alternative workaround?

Or are Microsoft customers best served by firing up a bittorrent program and trying their luck?