none
Checksum for windows.ISO created by MS mediacreationtool.exe RRS feed

  • Question

  • Primary question - What is the sha1 {&/or Md5} checksum for the "windows.ISO" file downloaded when using the MS supplied "mediacreationtools.exe"? I specifically want the checksum for the ISO resulting from selecting Language: English {UK} Edition: Windows 8.1 Architecture: 64-bit {x64}

    Situation - I am wanting to do a clean install of win 8.1 {build9600} onto a laptop which has a barely usable build 9600 already installed, damaged recovery partitions, and no OEM recovery media.

    I have downloaded and used the Microsoft supplied tool 'mediacreationtool.exe' which subsequently downloads a file called 'Windows.iso'. I wish to verify the integrity of that ISO file to ensure it arrived correctly. Obviously I want to do that **before** I repartition the HD and attempt to re-install OS rather than simply cross my fingers and hope all goes well.

    I have searched for a checksum or other method to ensure the ISO is 'good' yet could not find one.

    I downloaded a second copy of the same type of ISO using the same method with the same tool. I had hoped for the same checksum on both ISOs as a means of verification.

    If the 'media creation tool' uses an 'automatic' checksumming/correction as part of the download process to ensure the integrity of the downloaded ISO then it appears to be untrustworthy given that the two ISOs it gave me, which should have been the same, unfortunately arrived with different checksums.

    It is obviously ludicrous to continue downloading >3GB files until I find a pair whose checksum match. I am frustrated by this situation.

    I presume Microsoftland employs at least a few brainiacs who are capable of  understanding what checksums are and how they can be useful. Consequently I am astounded that MS does not publish the checksums for ISOs officially obtained from MS, using an official MS tool. Can anyone shed some light on why this situation exists and offer a useful remedy?


    • Edited by Yisit Sunday, March 22, 2015 3:55 PM
    Sunday, March 22, 2015 2:55 PM

Answers

  • Hi,

    Here is my conclusion.

    From the process of building the iso, I'm afraid the SHA1 will always be different. It seems that the tool downloading all files as temp files and "create" the ISO - since it is created locally, the SHA1 value must be different each time we downloading. 

    At this situation I'm afraid we will not have a method to fully authenticate this iso though it comes from Microsoft website.

    You can however check the size of the 2 files you downloaded and see if it is the same as mine.

    And here is my result.

    And it is Windows 8.1 x64 (not PRO, not -N, not -Single language).


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Wednesday, March 25, 2015 9:41 AM
    Moderator
  • Hi,

    Thank you for sharing all these information.

    For the story of the "Windows 8.1 update", I have to say that I can fully understand the trouble when a computer stopped from working after installing an update.

    Microsoft will publish service package for operation systems regularly. The most part of the purpose is to upgrade the system to support new features. However each time we upgrading a system to a higher service pack version, it may cause compatibility issues for both hardware and software - most of such issues can be fixed by upgrading a hardware driver or installing an update for a software. But sometimes manufacturers may not able to release a driver in-time, or some old app/hardware are stopped from supporting. In such situation, the system may not work well and we may not able to find a solution until we got a suitable update/driver.

    But still we recommended to update because of better performance and new features. Maybe we can contact device vendor before installing an important update such as a service pack to see if any known issue may occur, or just wait for some time until newer drivers are released. But unless there is a specific reason to keep the current situation, we still suggest to update in the end. 

    Back to your current issue. As we discussed, we may not able to find a way to verify the ISO it downloaded. Instead you can try to contact Microsoft Customer Service to see if they could provide an installation disk for you - I cannot confirm if it is an option due to different location and system version but you can have a try. Also if you have any friend who happens to have a retail version of installation disk, you can also use it as all installation disk (retail) are the same. 

    Again sorry for the inconvenience and hope you can get a solution!


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, March 30, 2015 9:53 AM
    Moderator

All replies

  • Hi,

    Above all, MSDN website provided SHA1 of most installation media. Please see: 

    https://msdn.microsoft.com/subscriptions/securedownloads/hh442898

    However from your test the SHA1 may not the same as the MSDN version.

    A quick workaround is to create a VM (or using another computer) to build a new system with the ISO file you just downloaded to see if it will work. It will cause some time but we could know if it is completely downloaded.


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, March 23, 2015 8:44 AM
    Moderator
  • Hi Shaon. Thankyou for your response.

    It appears to be that the MSDN site you provided a link to *cannot* provide a checksum for my needs because it does not provide any single edition 'Core' ISOs at all.

    Perhaps Shaon I am missing a significant bit of knowledge which should firstly be established. Is a consistent checksum even possible when using the official MS 'Windows Installation Media Creation Tool'?  The mystifying absence of verifying checksums, by both MS and users alike, begs this question.

    Eg, If customer "A" in England used the 'Media Creation Tool' to download the ISO for the UK language, 64-bit 'regular' {ie. non-"N", non-"Single-Language"} 'Core' edition of win8.1 and then hashed the resulting ISO can customer "B" in Australia, using the same tool to download the same product, expect to receive the same ISO with the same checksum ?

    If Yes, where can I *really* find these common checksums ?

    If No, what might be the differences between the ISOs received by customers "A" and "B" which would lead to different checksums and how might these differences affect the integrity of any files within the ISO ?

    Whilst I am miffed by the 'need' created for any sort of workaround,  I thankyou Shaon for your advice re testing the ISOs in a VM or on another system. I wasn't able to test with a VM yet I could do so the 'old fashioned way'.

    My first DVD failed to boot. Later on I could reasonably say this resulted from a "known bad" download.

    My second DVD made from the other ISO managed to complete the setup. This surprised me greatly because I had witnessed the internet connection fall over during the download of that ISO. Whether it can also successfully install on a UEFI machine such as it's intended target remains to be tested.

    Whist the outcome is ostensibly sufficient I nonetheless feel like an accountant who has ended up with more cash than listed in the books - I can't yet trust the process. The MS tool gave me one  bad download yet *zero* indication of any failure. How can I be *certain* that the other ISO is not corrupted in any way ?

    You say we "could know if it is completely downloaded" using this 'suck it and see method'. Given that the second ISO resulted in the ability to install the OS does this **absolutely guarantee** the integrity of the ISO and of every file within it or does it merely indicate that the files are "probably" OK ?

    'Best practice' dictates I verify the file is true before moving forward. Doing this seems to be especially pertinent given the 'troubled' driver environment which, according to the countless first hand accounts I have stumbled across, has followed the introduction of win8.1update1 {aka "win9"}. If there's a rattle or a groan after I start loading drivers I don't want to - and shouldn't have to - look backwards and wonder if the root cause is a dodgy system file resulting from corrupted install media.

    The sha1 Checksum for the UK English, x64, Core 'windows.iso' I have is --

    d81aea693dd977059c924d81e18a4dc1b2cc9071

    What's yours?




    • Edited by Yisit Tuesday, March 24, 2015 10:34 PM
    Tuesday, March 24, 2015 3:39 AM
  • Hi,

    Here is my conclusion.

    From the process of building the iso, I'm afraid the SHA1 will always be different. It seems that the tool downloading all files as temp files and "create" the ISO - since it is created locally, the SHA1 value must be different each time we downloading. 

    At this situation I'm afraid we will not have a method to fully authenticate this iso though it comes from Microsoft website.

    You can however check the size of the 2 files you downloaded and see if it is the same as mine.

    And here is my result.

    And it is Windows 8.1 x64 (not PRO, not -N, not -Single language).


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Wednesday, March 25, 2015 9:41 AM
    Moderator
  • 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?

    Saturday, March 28, 2015 6:12 PM
  • Hi,

    Thank you for sharing all these information.

    For the story of the "Windows 8.1 update", I have to say that I can fully understand the trouble when a computer stopped from working after installing an update.

    Microsoft will publish service package for operation systems regularly. The most part of the purpose is to upgrade the system to support new features. However each time we upgrading a system to a higher service pack version, it may cause compatibility issues for both hardware and software - most of such issues can be fixed by upgrading a hardware driver or installing an update for a software. But sometimes manufacturers may not able to release a driver in-time, or some old app/hardware are stopped from supporting. In such situation, the system may not work well and we may not able to find a solution until we got a suitable update/driver.

    But still we recommended to update because of better performance and new features. Maybe we can contact device vendor before installing an important update such as a service pack to see if any known issue may occur, or just wait for some time until newer drivers are released. But unless there is a specific reason to keep the current situation, we still suggest to update in the end. 

    Back to your current issue. As we discussed, we may not able to find a way to verify the ISO it downloaded. Instead you can try to contact Microsoft Customer Service to see if they could provide an installation disk for you - I cannot confirm if it is an option due to different location and system version but you can have a try. Also if you have any friend who happens to have a retail version of installation disk, you can also use it as all installation disk (retail) are the same. 

    Again sorry for the inconvenience and hope you can get a solution!


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, March 30, 2015 9:53 AM
    Moderator
  • Like Yisit, I assumed that the "mediacreationtool.exe" was just downloading the ISO. That explains why my checksums aren't matching for the same ISO downloaded multiple times.





    I've discovered that if you want the Windows 8.1 or Windows 10 ISOs that Microsoft displays checksums for on their TechNet site "http://technet.microsoft.com/en-us/subscriptions/downloads/", do the following:



    1) Use a web browser on a Linux system (I used Firefox on OpenSUSE 13.2) and go to "http://www.microsoft.com/en-us/software-download/windows8iso" or "http://www.microsoft.com/en-us/software-download/windows10iso".

    Note: I'm not sure if a Linux system is required but when I navigated to the URLs above on a Windows system, I got automatically redirected to "http://www.microsoft.com/en-us/software-download/windows8" or "http://www.microsoft.com/en-us/software-download/windows10" respectively where I was asked to download and run the 'mediacreationtool.exe'.

    Windows 7 ISOs are also available, but I think you need a retail product key "http://www.microsoft.com/en-us/software-recovery".



    2) Select the "region" edition of Windows 8.1 (e.g. K, N, Single Language - all ISOs come with Standard/Home and Pro) that you require and click confirm. Then select the language you require and click confirm. Note: TechNet does NOT provide checksums for Single Language "region" editions, for some reason.



    3) Click to download the 32bit and/or 64bit ISO. The page claims that links will be valid for 24-hours.





    So while you still can't verify Windows Single Language ISO checksums against Microsoft, at least you'll get consistent checksums. Hope this helps. Now that my account has been verified, I've added some images below. It seems like to get any decent paragraph separation you need to know HTML...












    Thursday, July 30, 2015 1:40 AM