Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Sunday, February 3, 2019 8:25 PM
I've been using WinPE and ImageX to capture image files on my Windows 7 computers. This has worked quite nicely for backing up the Windows system complete with all application software installed prior to the time of the backup. I've always run Windows computers starting with NT in a multi-boot configuration and these image files make moving an instance of a Windows system from one partition/drive to another quite easy.
I've just recently decided to buy a more up-to-date computer which has pretty much forced me to Windows 10. Also, while Windows 7 serves my purposes very well I do recognize that Microsoft will be ditching it pretty soon. My intention is to run the new computer he same way I've always run Windows (BTW this same concept also works very nicely with Linux and by doing things this way I'm able to run both Linux and Windows on the same computer). Since I already have WinPE with ImageX installed and running including scripts and workflow, it would be very desirable to use what I have that works nicely rather than rebuild, test, and relearn how to do the same thing with different software.
Does anyone know if ImageX can make a proper image file (i.e., that works with Windows 10 installer) from a Windows 10 partition?
All replies (12)
Sunday, February 3, 2019 8:51 PM ✅Answered
i would not use ImageX,
the new tool for that is DISM is very simlar and full supported from MS.
what is the reason to use the old "imageX".. .
MS info ==> /en-us/windows-hardware/manufacture/desktop/capture-and-apply-windows-system-and-recovery-partitions
Please Mark This As Answer if it solved your issue
Please Vote This As Helpful if it helps to solve your issue
N 48° 8' 39.8419" E 11° 36' 1.3359"
Klaus
Tuesday, February 12, 2019 8:28 PM ✅Answered
After considerable hacking around with a pretty inflexible Windows 10 installer it was possible to use the successfully created install.wim file to reinstall that system onto another drive. While there is still a lot to learn about Windows 10 it is possible to say that WinPE can be used to create a system image that can be used to reinstall/recover a Windows 10 system.
Also, the Windows 7 WinPE does not seem to want to run on this computer, which pertains to how this topic got started before drifting into other concepts. The booting seems to function normally but the keyboard is inoperative. My current suspicion is that this has to do with the difference between the BIOS on the new computer and the rather old computer on which the WinPE disk was created. There is no intention to further troubleshoot this finding but I think it possible to say there is an answer of sorts to the original question.
Monday, February 4, 2019 7:14 PM
When saying, "it would be very desirable to use what I have that works nicely rather than rebuild, test, and relearn how to do the same thing with different software." I was trying to explain my reasoning.
However, this is Windows and Microsoft works very hard at trying to obsolete their own products even when they work real good and do everything you want. I have no need for anything that Windows 10 provides, that I know of, which isn't available in Windows 7, XP, or even 2000. Actually NT was pretty good but 2000 did add some capability which I did appreciate. I suppose my view of the world would be that the operating system should be kept separate from the application software but this clearly doesn't fit the Microsoft marketing strategy. Microsoft's need to change the UI (i.e., different way to do the same stuff) is especially exasperating. The good news is that lots of applications have been developed (in some cases converted) for Windows and those developers are motivated to avoid making them platform dependent. In this regard I've become a big fan of portable apps now that we have very inexpensive but fast portable storage.
Well I suppose that's more preaching than is called for on this site but I do appreciate the advice and will see if I can adapt the new software to my work-flow.
Monday, February 4, 2019 7:47 PM
well I just try you to help..
the new OS is really stable and fast and much secure as the old one.
start Play with it..
and of course i know excaltly what you talking about - even more as you can image.
each day.. ;.)
Please Mark This As Answer if it solved your issue
Please Vote This As Helpful if it helps to solve your issue
N 48° 8' 39.8419" E 11° 36' 1.3359"
Klaus
Sunday, February 10, 2019 9:00 PM
Well now, I went to the trouble of building a new WinPE drive from the Windows 10 ADK. However, when I run DISM to capture a partition image of the Windows 10 system as I've been doing easily for some time now on Windows 7 using WinPE along with ImageX it fails part way through the process. The command I used is as follows:
Dism /Capture-Image /Compress:fast /CheckIntegrity /Verify /CaptureDir:D: /ImageFile:.\install.wim /Name:Win10A /Description:"Original Dell Install with Avast, Firefox, Chrome"
DISM ran for a couple of hours (approximately) and the progress indicator showed 27% when it failed. The resulting image file exceeds 13GB which is bigger than I would have expected after a successful completion. This is basically an out of the box Windows 10 system with only a few applications installed. McAfee software (and apps whatever those are) were removed prior to installing Avast Free Anti-virus along with Firefox and Chrome browsers. Does that really take more than 13GB after any kind of compression?
I suppose the real clue to what went wrong should be in the log file which is also much to huge for posting here. However, it does end with error indications (that don't mean much to me) as shown below (at end of the post). There does appear to be some information suggesting an out of space condition on the X: drive which is the RAM disk built by WinPE. I don't think this is anything that we end users have either any influence over or ability to adjust. To be sure I did nothing to affect what is stored on the X: drive.
About the only thing I have any control over in this situation is the command which in this case was formed by trying to replicate what has been working great for me with ImageX on Windows 7.
Records from dism.log follow:
1976] [0xc144012f]
[1976] [0xc144012f]
[1976] [0xc144012f]
[1976] [0xc144012f]
[1976] [0xc144012f]
[1976] [0xc144012f]
[1976] [0xc144012f]
[1976] [0xc144012f]
[1976] [0xc144012f]
[1976] [0x80070070] ReadWriteDataInternal:(142): There is not enough space on the disk.
[1976] [0x80070070] WriteDataCallback:(409): There is not enough space on the disk.
[1976] [0x80070070] UncompressFile:(1151): There is not enough space on the disk.
[1976] [0x8144012d]
2019-02-09 16:55:41, Warning DISM DISM WIM Provider: PID=1976 [UncompressFile:(1215) -> WriteData failed] X:\windows\TEMP\fcb31752-57f0-42c6-9a6c-dacb4f3efa3a (HRESULT=0x80070070) - CWimManager::WimProviderMsgLogCallback
[1976] [0x80070070] ResExtract:(513): There is not enough space on the disk.
[1976] [0x8144012d]
2019-02-09 16:55:41, Warning DISM DISM WIM Provider: PID=1976 [ResExtract:(515) -> UncompressFile failed] X:\windows\TEMP\fcb31752-57f0-42c6-9a6c-dacb4f3efa3a (HRESULT=0x80070070) - CWimManager::WimProviderMsgLogCallback
[1976] [0x81440133]
[1976] [0x80070050] ResExtract:(649): The file exists.
[1976] [0x80070050] AddCaptureNodeToImage:(475): The file exists.
[1976] [0xc144012e]
2019-02-09 16:57:36, Error DISM DISM WIM Provider: PID=1976 D:\ProgramData\Package Cache\C9552825-7BF2-4344-BA91-D3CD46F4C441}v1.50.369.0\iclsClientInstaller_x86.msi (HRESULT=0x80070050) - CWimManager::WimProviderMsgLogCallback
[1976] [0x80070050] ProcessWimQueueNode:(98): The file exists.
[1976] [0x80070050] DequeueWimData:(304): The file exists.
[1976] [0x80070050] ImageWorkerThread:(250): The file exists.
[1976] [0x80070050] GetImageErrorCode:(2837): The file exists.
[1976] [0x80070050] ResAddFromFileAndHandle:(497): The file exists.
[1976] [0xc144012e]
2019-02-09 16:57:36, Error DISM DISM WIM Provider: PID=1976 D:\Users\Public\NTUSER.DAT (HRESULT=0x80070050) - CWimManager::WimProviderMsgLogCallback
[1976] [0x80070050] AddFileNodeToImage:(897): The file exists.
[1976] [0x80070050] EnumImageFiles:(135): The file exists.
[1976] [0x80070050] EnumImageFiles:(154): The file exists.
[1976] [0x80070050] EnumImageFiles:(154): The file exists.
[1976] [0x80070050] WriteFileImage:(1004): The file exists.
[1976] [0x80070050] GetImageErrorCode:(2837): The file exists.
[1976] [0x80070050] WriteDirImage:(1488): The file exists.
2019-02-09 16:57:36, Error DISM DISM WIM Provider: PID=1976 TID=1952 onecore\base\ntsetup\opktools\dism\providers\wimprovider\dll\wimmanager.cpp:1193 - CWimManager::Capture(hr:0x80070050)
[1976] [0xc144012e]
2019-02-09 16:57:36, Error DISM DISM WIM Provider: PID=1976 [WIMCloseWIM:(2782) -> Fail to flush file buffers] F:\Dell3670\WinImages\Win10A\install.wim (HRESULT=0x80070006) - CWimManager::WimProviderMsgLogCallback
2019-02-09 16:57:36, Error DISM DISM WIM Provider: PID=1976 TID=1952 onecore\base\ntsetup\opktools\dism\providers\wimprovider\dll\wimmanager.cpp:4626 - CWimManager::InternalCmdCaptureBase(hr:0x80070050)
2019-02-09 16:57:36, Error DISM DISM WIM Provider: PID=1976 TID=1952 "Error executing command" - CWimManager::InternalExecuteCmd(hr:0x80070050)
2019-02-09 16:57:36, Error DISM DISM WIM Provider: PID=1976 TID=1952 onecore\base\ntsetup\opktools\dism\providers\wimprovider\dll\wimmanager.cpp:2203 - CWimManager::ExecuteCmdLine(hr:0x80070050)
2019-02-09 16:57:36, Error DISM DISM.EXE: WimManager processed the command line but failed. HRESULT=80070050
2019-02-09 16:57:36, Info DISM DISM.EXE: Image session has been closed. Reboot required=no.
2019-02-09 16:57:36, Info DISM DISM.EXE:
2019-02-09 16:57:36, Info DISM DISM.EXE: < Ending Dism.exe session >
2019-02-09 16:57:36, Info DISM DISM.EXE:
2019-02-09 16:57:36, Info DISM DISM Provider Store: PID=1976 TID=1952 Found the OSServices. Waiting to finalize it until all other providers are unloaded. - CDISMProviderStore::Final_OnDisconnect
2019-02-09 16:57:36, Info DISM DISM Provider Store: PID=1976 TID=1952 Disconnecting Provider: FolderManager - CDISMProviderStore::Internal_DisconnectProvider
2019-02-09 16:57:36, Info DISM DISM Provider Store: PID=1976 TID=1952 Disconnecting Provider: FfuManager - CDISMProviderStore::Internal_DisconnectProvider
2019-02-09 16:57:36, Info DISM DISM Provider Store: PID=1976 TID=1952 Disconnecting Provider: WimManager - CDISMProviderStore::Internal_DisconnectProvider
2019-02-09 16:57:36, Info DISM DISM Provider Store: PID=1976 TID=1952 Disconnecting Provider: VHDManager - CDISMProviderStore::Internal_DisconnectProvider
2019-02-09 16:57:36, Info DISM DISM Provider Store: PID=1976 TID=1952 Disconnecting Provider: GenericImagingManager - CDISMProviderStore::Internal_DisconnectProvider
2019-02-09 16:57:36, Info DISM DISM Provider Store: PID=1976 TID=1952 Disconnecting Provider: Compatibility Manager - CDISMProviderStore::Internal_DisconnectProvider
2019-02-09 16:57:36, Info DISM DISM Provider Store: PID=1976 TID=1952 Releasing the local reference to DISMLogger. Stop logging. - CDISMProviderStore::Internal_DisconnectProvider
Sunday, February 10, 2019 9:04 PM
well quick check of the log
[1976] [0x80070070] ReadWriteDataInternal:(142): There is not enough space on the disk.
[1976] [0x80070070] WriteDataCallback:(409): There is not enough space on the disk.
[1976] [0x80070070] UncompressFile:(1151): There is not enough space on the disk.
you are sure that your disk has engouh space ?
klaus
Klaus
Monday, February 11, 2019 4:28 AM
There are 2 disks involved, that I can control, which are both USB flash drives. One is the WinPE boot disk. The other is for storing the partition image (.wim) file produced by the Dism tool. The later has a total capacity of 115GB with approximately 6GB that are being used. I did err in making my previous post. I now see that the install.wim file, that resulted from the failed operation, is only 13MB rather than GB as I previously stated. Apparently I confused a KB for MB. The WinPE disk has only a bit more than 7GB of capacity of which 300MB are being used for WinPE storage. I also believe that WinPE dynamically creates and runs from a RAM disk, mounted as the X: drive, that I did not think to check at the time because I didn't try to examine the log file while booted under WinPE. However, the amount of RAM on the computer is 8GB. Because the USB drives have plenty of unused storage I was suspecting the problem could be with the RAM disk and of course I have no idea how it might be used by the Dism tool.
Never had any problem doing the same thing on Windows 7 and Microsoft wants us to think this is better.
Monday, February 11, 2019 6:18 PM
The problem with imagex.exe: Microsoft released imagex.exe and recommended for recovery, but a year later that decided to pull it and say it couldn't shipped and used in the field. The did have a WIM API set available it one wanted to create their own tool.
Eventually, they added WIM support to DISM, which replaces imagex. With the latest release of Windows 10, they added the ability to capture whole disks using DISM to .FFU files.
http://www.annabooks.com/Articles/Articles_IoT10/Win10IoT-E-FFU-Capture-Restore%20Rev1.4.pdf
Would a whole disk capture help you?
Sean Liming - Book Author: Starter Guide Windows 10 IoT Enterprise - www.annabooks.com / www.seanliming.com
Monday, February 11, 2019 7:42 PM
My interest is in setting up a single computer. The big problem with the approach to recovery being pushed by both Microsoft and computer vendors is that you are NOT expected to experience it until you need it. Then when it fails you are in a bit of a pickle as I find myself right now. The good news is that I haven't yet acquired any dependency for this computer but if I can do what I want right now I'll be very well prepared to fix it when it breaks.
My approach to recovery involves capturing a partition/system image that can be used to recreate that partition/system. An implication of this is that functioning Windows system is completely contained in a single partition but functioning precludes any need for recovery tools. Note: I turn off restore points. I'd never use such a thing. The capture occurs at the times when I know the system is working well to include desired configuration, settings, and application software from many sources. That image is then reinstalled one or more times in a multi-boot environment. This means I know I have multiple working instances of the same system. Should one start acting strangely I don't have to stop what I'm doing and troubleshoot the problem I simply reboot the computer to another instance that does work. In fact, should the trouble shooting ever become perplexing, as what I'm doing now, I don't have to waste any time doing it. I simply re-install the working instance onto the partition that has become problematic. This approach does involve storing all of the user data in separate partitions. This includes temporary storage, pagefile, etc.
I suppose the big negative to my approach is the idea of creating the recoverable system image prior to using the computer as well as from time to time as appropriate. Just catching up with Windows Update is good to do periodically. I suspect many/most users might find this undesirable.
On Windows XP and prior versions of Windows I ended up relying on some OEM software to do this because the tools supplied by Windows were simply inadequate. However, with Windows 7 (likely also Vista which I never experienced) the combination of Windows PE and ImageX ended up making a big improvement. That combination along with a Windows installer included everything that is needed to do the job. It should be noted that in this situation I'm not looking to "Generalize" anything. In fact, what I want is all device support and other customization to be preserved.
I want to run Windows 10 the same way.
For whatever it might be worth this same approach works well on Linux also but setting up the original configuration is a bit more complicated in that case.
Tuesday, February 12, 2019 2:23 AM
New news!
Decided to give it a try using the same command specification as what is described in ADK documentation which means using the command that follows:
Dism /Capture-Image /CaptureDir:D: /ImageFile:".\install.wim" /Name:"Win10A" /Description:"Original Dell Install with Avast, Firefox, Chrome"
This successfully created a partition image (.wim) which I have yet to do anything with so I don't know how good it is. Suggestion is that removing the options I'd specified based on command reference description for Dism seems to have fixed the problem. The options originally included were the following:
/Compress:fast /CheckIntegrity /Verify
Which one might have caused the problem is still a mystery but this does suggest that Dism may be a bit flaky (i.e. not too robust).
Wednesday, February 13, 2019 10:04 PM
JFYI: Imagex.exe is still available, updated, in the current ADK.
Thursday, February 14, 2019 3:18 PM
That is good, for me anyway, to know. I'll take a look and see what it can do.
Many thanks!!!