70 replies to this topic

[Atari800XL]

Wait, it's probably a language thing... My PESE and WinRE are Dutch, my WinPE is en-US...

Sorry, didn't think of that, will rebuild PESE with en-US source tomorrow...

 

Thanks for sticking in there! (Well, until now most issues have been somewhat "productive" for any future howto's, for example "ignore registry import errors", etc.)

Edited by Atari800XL, 28 July 2016 - 08:11 PM.

[spleenharvester]

Wait, it's probably a language thing... My PESE and WinRE are Dutch, my WinPE is en-US...

Sorry, didn't think of that, will rebuild PESE with en-US source tomorrow...

 

Thanks for sticking in there! (Well, until now most issues have been somewhat "productive" for any future howto's, for example "ignore registry import errors", etc.)

 

Certainly possible - good luck! And yeah, could be a lifesaver for others trying to do this - shame I can't edit the OP. 

[Atari800XL]

Success!! I made a new basic Win10PESE build (enUS this time), used enUS PE and enUS PESE, ran my new script on it (takes 2 minutes) and things are working just fine. Sorry for being so stupid...

Next issue for me is a bit of a strange one: If I run XYPlorer (which is 32bit only), I get an error ("-2147319780"), which I never have on a normal PESE. The odd thing is: if I run my old portable Excel '97 first and then try XYPlorer again, it runs fine! Running this old Excel in PE is just a "joke", actually, and I found out by accident it fixes the XYPlorer issue, but running it must do "something" to fix the issue. Maybe it does some initializing somewhere, but I can't tell what or where. I ran Procmon on it and compared "before and after Excel", but couldn't find anything. Spleen, what exactly did you do to fix your XYPlorer issue?

[spleenharvester]

Success!! I made a new basic Win10PESE build (enUS this time), used enUS PE and enUS PESE, ran my new script on it (takes 2 minutes) and things are working just fine. Sorry for being so stupid...

Next issue for me is a bit of a strange one: If I run XYPlorer (which is 32bit only), I get an error ("-2147319780"), which I never have on a normal PESE. The odd thing is: if I run my old portable Excel '97 first and then try XYPlorer again, it runs fine! Running this old Excel in PE is just a "joke", actually, and I found out by accident it fixes the XYPlorer issue, but running it must do "something" to fix the issue. Maybe it does some initializing somewhere, but I can't tell what or where. I ran Procmon on it and compared "before and after Excel", but couldn't find anything. Spleen, what exactly did you do to fix your XYPlorer issue?

 

Great to hear! As for XYplorer, all I had to do was regsvr32 syswow64\oleaut32.dll. I think I originally had the same error as you. Things you can try:

 

1) Look at process monitor for file dependency issues. Nvm I see that you did this.

 

2) If nothing obvious sticks out, run the following from command prompt to rule out DLL registration issues (sometimes they don't get carried over with the syswow64 regkeys, I am not sure why):

dir /b x:\windows\syswow64 >x:\wow64.txt
for /f "delims=*" %a in (x:\wow64.txt) do (x:\windows\syswow64\regsvr32.exe /s x:\windows\syswow64\%a)

3) If that still doesn't fix it, launch RegShot and take a shot before and after opening excel, then compare.

 

I notice that WinPE seems to be missing some OLE-related functions at stock compared to WinRE (Multicommander etc wouldn't run either because oledlg.dll was missing). I'm guessing it's either a DLL registration issue or OLE-related regkeys are missing.

 

EDIT ~ Also does XYplorer give you any more details on the error other than code?

Edited by spleenharvester, 29 July 2016 - 04:02 PM.

[Wonko the Sane]

 

I notice that WinPE seems to be missing some OLE-related functions at stock compared to WinRE (Multicommander etc wouldn't run either because oledlg.dll was missing). I'm guessing it's either a DLL registration issue or OLE-related regkeys are missing.

 

Seemingly OT, but JFYI, a good ol' way to check/fix:
http://reboot.pro/to...10-mb/?p=154017

 

Wonko

[spleenharvester]

Seemingly OT, but JFYI, a good ol' way to check/fix:
http://reboot.pro/to...10-mb/?p=154017

 

Wonko

 

Ooh neat, thankyou for this!

[Atari800XL]

regsvr32 syswow64\oleaut32.dll. I think I originally had the same error as you.

 

Yep, this did the trick:

x:\windows\syswow64\regsvr32.exe /s x:\windows\syswow64\oleaut32.dll

I believe I had tried that before, but that must have been back when I had the languages mixed up.

(BTW: So XY could have registered this itself, like Excel did?)

So now I have my favorite file explorer working. It's actually an old (free giveaway) version: 11.90. Normally, free versions don't have the nice "portable file associations" feature, but 11.90free has it. Launching documents from XY always starts the correct program, associating them is very easy from an ini file. Very easy to configure, works on any OS (incl. PE), I use it on all systems. Great on w10 as well (which keeps "stealing" assocs).

Just wanted to share why I like XY so much. Of course, the author could/ should have made a 64bit version by now...

 

With XY as my file explorer, TCCLE as command line, and Autohotkey as PE shell (!), things are starting to look pretty good. (Ask me about ahk as a PE shell...), Oh, and of course WinNTSetup for OS installs, and TSE as text editor. Etc., etc.

[spleenharvester]

Yep, this did the trick:

x:\windows\syswow64\regsvr32.exe /s x:\windows\syswow64\oleaut32.dll

I believe I had tried that before, but that must have been back when I had the languages mixed up.

(BTW: So XY could have registered this itself, like Excel did?)

So now I have my favorite file explorer working. It's actually an old (free giveaway) version: 11.90. Normally, free versions don't have the nice "portable file associations" feature, but 11.90free has it. Launching documents from XY always starts the correct program, associating them is very easy from an ini file. Very easy to configure, works on any OS (incl. PE), I use it on all systems. Great on w10 as well (which keeps "stealing" assocs).

Just wanted to share why I like XY so much. Of course, the author could/ should have made a 64bit version by now...

 

With XY as my file explorer, TCCLE as command line, and Autohotkey as PE shell (!), things are starting to look pretty good. (Ask me about ahk as a PE shell...), Oh, and of course WinNTSetup for OS installs, and TSE as text editor. Etc., etc.

 

Seemingly Excel must have done - doesn't surprise me that MS could add 'self-repair' functions like that if it detects a registry problem.

 

I really hope a 64-bit version of XY is released. It's a really incredible program, but it has issues with WoW64 redirection in this environment - any attempts to open a .reg, .vbs or .msc file will fail because it's being redirected to WoW64, and 10PESE doesn't have WoW64 versions of regedit, MMC and others. I'm very tempted to add the dependencies for them in WoW64 manually in the meantime because it is so much better than multicommander.

 

Theoretically it wouldn't be that hard to add support for blocking redirection for those programs since the program is capable of doing so when viewing system32, but I suppose this very niche scenario is the only time that it would be necessary.

 

(Also had never heard of any of those other programs you mentioned - they look useful!)

Edited by spleenharvester, 29 July 2016 - 05:58 PM.

[Atari800XL]

See, that's why I insist on a XY version with Portable File Associations.

Example (xyplorer.ini):

[FileAssoc]

1=+"Open with Sumatra" pdf>"C:\Program Files\SumatraPDF\SumatraPDF.exe" -esc-to-exit

2=+"Open with TSE" xml>c:\program files\tse\q.exe
3=+"Open with UltraISO" iso> C:\Program Files\Utilities\UltraISO\UltraISO.exe
etc.

 

As long as you keep the ini with the XYPlorer exe, you always have the correct program opening your documents (like I said, great for PE, but also great for Windows 10 and its stupid Metro associations).

 

Oh, and by the way: No chance of a 64bit version anytime soon, I'm afraid.

Edited by Atari800XL, 29 July 2016 - 06:10 PM.

[spleenharvester]

Update for 02/08/16 - I can confirm this still works on the Anniversary update, but a few notes:

• You need to make all your regkeys etc again from scratch. If you use the SxS keys for 10.0.586.0 at any stage you will get CRITICAL_PROCESS_DIED.
• If you have just installed the Anniversary update and have not received further updates you can export the SxS keys from your own running installation.
• win32u.dll and gdi32full.dll are new dependencies for syswow64 in 14393 necessary for many programs to work.

 

I am also working on translating 5-WoW64.script/part of 1-Files.script to batch form to bypass the Winbuilder steps entirely, which generates WinSxS, Syswow64 and System32\catroot for you from a source. Used it to successfully add WoW64 to my new anniversary image, and it has only added 56mb to the WIM size. Will upload when some things have been smoothed out.

Edited by spleenharvester, 03 August 2016 - 02:13 AM.

[Wonko the Sane]

I am also working on translating 5-WoW64.script/part of 1-Files.script to batch form to bypass the Winbuilder steps entirely, which generates WinSxS, Syswow64 and System32\catroot for you from a source. Used it to successfully add WoW64 to my new anniversary image, and it has only added 56mb to the WIM size. Will upload when some things have been smoothed out.

Wonko approves of this batch "translation" , though you cannot really use "only" to refer to 56 Mb (you will need a special license for that ).


Wonko

[Greg13]

Hello thanks for the tutorial but i have a problem when i want to add some registry keys, if i do this manually with regedit it return "Some keys are open by the system or other processes." and if i do in command line with reg.exe it return "access error to registry" Does somebody have solution ? thanks by advance everybody Sorry if my english is not so good that your

 

 

I have make a modded batch file based from Atari800XL work

@Echo Off

If "%1"=="" goto Usage
If "%2"=="" goto Usage
If "%3"=="" goto Usage

Mkdir temp
:: Testing File
If NOT exist %1 (
	Echo File : %1
	Echo Not Found ...
	Pause
	Goto End
)
If NOT exist %2 (
	Echo File : %2
	Echo Not Found ...
	Pause
	Goto End
)	
:: Export hive from PESE
7z.exe x %1 -otemp\pese\hive windows\system32\config
If not exist temp\pese\hive\windows\system32\config\system (
	Echo Error whil extrating file on PESE.WIM
	Pause
	Goto Clear
	)
)

:: Export reg key from pese hive
Mkdir temp\pese\reg
reg load hklm\sys temp\pese\hive\windows\system32\config\system
reg load hklm\soft temp\pese\hive\windows\system32\config\software
reg export "hklm\sys\ControlSet001\Control\Session Manager" temp\pese\reg\01sys-bootexecute.reg
reg export "hklm\soft\Microsoft\Windows\CurrentVersion\SideBySide" temp\pese\reg\02sidebyside.reg
reg export "hklm\soft\WOW6432Node" temp\pese\reg\03wow6432node.reg
reg export "hklm\soft\Classes\WOW6432Node" temp\pese\reg\04classeswow6432node.reg
reg export "hklm\soft\Microsoft\Windows\CurrentVersion\SMI\WinSxS Settings" temp\pese\reg\05smi.reg
reg unload hklm\sys
reg unload hklm\soft

:: Export PESE files
7z.exe x %1 -otemp\pese\files Windows\WinSxS
7z.exe x %1 -otemp\pese\files Windows\System32\Catroot
7z.exe x %1 -otemp\pese\files Windows\SysWOW64
7z.exe x %1 -otemp\pese\files Windows\System32\wow64.dll
7z.exe x %1 -otemp\pese\files Windows\System32\wow64cpu.dll
7z.exe x %1 -otemp\pese\files Windows\System32\wow64win.dll
7z.exe x %1 -otemp\pese\files Windows\System32\loadWOW64.exe

::Export raw PE from orginal boot wim
wimlib-imagex.exe export --boot %2 1 %3

:: Deleting WinSxS from the raw PE
wimlib-imagex.exe update %3 1 --command="delete \Windows\WinSxS --recursive"

:: Export hive from raw pe
7z.exe x %3 -otemp\pe\hive windows\system32\config
:: Import PESE reg key to raw PE
reg load hklm\sys temp\pe\hive\windows\system32\config\system
reg load hklm\soft temp\pe\hive\windows\system32\config\software
reg import temp\pese\reg\01sys-bootexecute.reg
reg import temp\pese\reg\02sidebyside.reg
reg import temp\pese\reg\03wow6432node.reg
reg import temp\pese\reg\04classeswow6432node.reg
reg import temp\pese\reg\05smi.reg
reg unload hklm\soft
reg unload hklm\sys

:: Update file and registry in raw PE 
echo delete 'windows\system32\config' --force --recursive > temp\wim-update.txt
echo add 'temp\pe\hive' '' >> temp\wim-update.txt
echo add 'temp\pese\files' '' >> temp\wim-update.txt
wimlib-imagex.exe update %3 1 <"temp\wim-update.txt"

:Clear
rmdir temp /s /q
Goto End

:Usage
CLS
Echo.
Echo ThisBatch.bat pese_wim boot.wim new_wim
Echo.
Echo 	*** "pese_wim" is a PESE 64bit with 32Bit support idealy from spam
Echo 	*** "boot.wim" from original Windows Setup
Echo 	*** "new_wim" your final RAW PE 64bit with 32Bit support
Echo.
Echo ----------
Echo \ Original script from "Atari800XL", Modded by Greg13
Echo / Based on "spleenharvester" from Reboot.pro
Echo ----------
Pause

:End

Edited by Greg13, 22 April 2017 - 08:34 AM.

[misty]

@Greg13
Without having access to your registry entries it's difficult to know which entry/entries are causing problems.

I had a similar issue in MistyPE and use a workaround - adding the necessary entries via a batch script executed by winpeshl.ini.

Alternatively you could use Erwan's excellent Offlinereg - this can bypass the security permissions in the registry.

Misty

P.s. Why use a PESE build as a base? It's possible to obtain all of the required SysWoW64 files from the same RTM .iso containing your boot.wim file.

[Greg13]

Hello thanks for quick answer, i will going to try Offlinereg  

 

I use PESE build, for falow the tutorial of spleenharvester, in the pese build of spam the file of SysWoW64 are not patched ?

Edited by Greg13, 22 April 2017 - 10:37 AM.

[erwan.l]

Hello thanks for quick answer, i will going to try Offlinereg  
 
I use PESE build, for falow the tutorial of spleenharvester, in the pese build of spam the file of SysWoW64 are not patched ?

Hi Greg,
If you need help with offlinereg you can PM me in french if you wish.

Cheers,
Erwan

[Greg13]

Thanks, dont worry offlinereg is easy to use I just do not understand why it does not manage export...

 

 

But (yes another one problem) when all is do i have a new error message :

 

 

 

SYSTEMROOT directory(X:\Windows) is different from the configured one (x:\Windows~BT\Windows)

Edited by Greg13, 26 April 2017 - 12:41 PM.

[Greg13]

I have solved my problem with DISM /Set-TargetPath:X:\ (Link)

But ... I have a Side-By-Side error... while i have fully export and import Side-By-Side registry key of PESE, i don't have any idea for this if someone have solution?

 

(i Make my english training when i wrote a new post lol    My english is corect for moment ?)

[armixen]

I am trying to do something very similar to this.

 

My goal is to add x86 app support to an ARM64 WinRE instance.

 

Preferably, a batch file, where I can just boot into the recovery console that ships with the OS, and run it from there, to prep the WinRE instance with the files and keys necessary to boot x86 apps.

 

I then plan to use my wide variety of x86 apps on the system (currently I cannot even image the system from a USB boot or similar).

 

I don't have an ARM64 ISO, just the actual ARM64 hardware with the 10 S OS pre-installed; so the PESE stuff is not really workable.

[stayboogy]

http://www.mediafire...atcher.zip/file

 

 

Here, I made this way easier for those who would just like to patch their base winpe image and add wow64 support

 

this is for v1803, build 17134.1 x64 winpe builds with the ADK.  this will patch your .wim and make it support x86 apps.

 

follow included README

 

x64_winpe_syswow_patcher.zip

CRC32: 941ECBB6
MD5: FB7B9CD8933B2ADE801992A6026F65F8
SHA-1: 2B0550734573722F0FC46E9E6B9AE1B75C92C06F
 

[armixen]

http://www.mediafire...atcher.zip/file

 

 

Here, I made this way easier for those who would just like to patch their base winpe image and add wow64 support

 

this is for v1803, build 17134.1 x64 winpe builds with the ADK.  this will patch your .wim and make it support x86 apps.

 

follow included README

 

x64_winpe_syswow_patcher.zip

CRC32: 941ECBB6
MD5: FB7B9CD8933B2ADE801992A6026F65F8
SHA-1: 2B0550734573722F0FC46E9E6B9AE1B75C92C06F
 

 

This is amazing!  

Do you reckon you can make one for ARM64 as well?  

That is, adding X86 to an ARM64 (instead of AMD64) WinRE.WIM file...

[armixen]

http://www.mediafire...atcher.zip/file


Here, I made this way easier for those who would just like to patch their base winpe image and add wow64 support

this is for v1803, build 17134.1 x64 winpe builds with the ADK. this will patch your .wim and make it support x86 apps.

follow included README

x64_winpe_syswow_patcher.zip

CRC32: 941ECBB6
MD5: FB7B9CD8933B2ADE801992A6026F65F8
SHA-1: 2B0550734573722F0FC46E9E6B9AE1B75C92C06F

So having followed these instructions, and DIFFing the default file and the patched file, what I see is:

1. The usual suspects. wow64*.dll in system32.
2. loadwow64.exe. Is the source code for this item available? I'd need to build it for ARM64 natively for my project.
3. A ton of stuff with the GUID {f750e6c3-38ee-11d1-85e5-00c04fc295ee} in the system32\catroot folder. Any idea what these are?
4. Updated registry. I'll need to DIFF those separately.
5. A ton of stuff in syswow64, naturally.
6. A ton of stuff in winsxs REMOVED! amd64_*. I wonder why these were removed? Do they do any harm?
7. Some VC++ 8.0&9.0 stuff added into winsxs - I suppose this is to support VC++ app runtimes.
8. \windows\winsxs\manifests\amd64_microsoft-windows-blb-engine-main_31bf3856ad364e35_10.0.17134.1_none_c962824f68ea4ec3.manifest added - what is this one for?
9. Added some more, possibly for common control, GDI+ support, etc.:
\windows\winsxs\manifests\x86_microsoft.windows.c..-controls.resources_6595b64144ccf1df_5.82.17134.1_en-us_a4ff9d8583b66ce7.manifest
\windows\winsxs\manifests\x86_microsoft.windows.c..-controls.resources_6595b64144ccf1df_6.0.17134.1_en-us_429312e5517c33ee.manifest
\windows\winsxs\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.17134.1_none_8ef454a057103afa.manifest
\windows\winsxs\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.1_none_2c87ca0024d60201.manifest
\windows\winsxs\manifests\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.17134.1_none_bcfdca399f684482.manifest
\windows\winsxs\manifests\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.17134.1_none_ac4f391e386e1e29.manifest
\windows\winsxs\manifests\x86_microsoft.windows.i..utomation.proxystub_6595b64144ccf1df_1.0.17134.1_none_d66746ec6b2f1a97.manifest
\windows\winsxs\manifests\x86_microsoft.windows.isolationautomation_6595b64144ccf1df_1.0.17134.1_none_2ceff5b90c250083.manifest
\windows\winsxs\manifests\x86_microsoft.windows.systemcompatible_6595b64144ccf1df_6.0.17134.1_none_34240ce3e16cf008.manifest
10. That's almost all of it. Overall, more files were REMOVED than added - what a surprise!

I wonder how much of this same recipe I can follow for ARM64 x86 support...which is the goal of the exercise for me here.

Edited by armixen, 16 December 2018 - 05:08 PM.

[misty]

I posted the Customising WinPE topic some time ago, which links to instructions for manually adding WoW64 support to WinPE - along with some other WinPE customisations.

Direct link to documentation - here.

Direct link to adding WoW64 to WinPE 10.* - here

loadWoW64.exe/setWOW64.exe may no longer be required - see here



Misty

[armixen]

I posted the Customising WinPE topic some time ago, which links to instructions for manually adding WoW64 support to WinPE - along with some other WinPE customisations.

Direct link to documentation - here.

Direct link to adding WoW64 to WinPE 10.* - here

loadWoW64.exe/setWOW64.exe may no longer be required - see here



Misty

 

That's all wonderful, mate!

 

But its not enough to build an ARM64 compatible image, innit?

[stayboogy]

So having followed these instructions, and DIFFing the default file and the patched file, what I see is:

1. The usual suspects. wow64*.dll in system32.
2. loadwow64.exe. Is the source code for this item available? I'd need to build it for ARM64 natively for my project.
3. A ton of stuff with the GUID {f750e6c3-38ee-11d1-85e5-00c04fc295ee} in the system32\catroot folder. Any idea what these are?
4. Updated registry. I'll need to DIFF those separately.
5. A ton of stuff in syswow64, naturally.
6. A ton of stuff in winsxs REMOVED! amd64_*. I wonder why these were removed? Do they do any harm?
7. Some VC++ 8.0&9.0 stuff added into winsxs - I suppose this is to support VC++ app runtimes.
8. \windows\winsxs\manifests\amd64_microsoft-windows-blb-engine-main_31bf3856ad364e35_10.0.17134.1_none_c962824f68ea4ec3.manifest added - what is this one for?
9. Added some more, possibly for common control, GDI+ support, etc.:
\windows\winsxs\manifests\x86_microsoft.windows.c..-controls.resources_6595b64144ccf1df_5.82.17134.1_en-us_a4ff9d8583b66ce7.manifest
\windows\winsxs\manifests\x86_microsoft.windows.c..-controls.resources_6595b64144ccf1df_6.0.17134.1_en-us_429312e5517c33ee.manifest
\windows\winsxs\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.17134.1_none_8ef454a057103afa.manifest
\windows\winsxs\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.1_none_2c87ca0024d60201.manifest
\windows\winsxs\manifests\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.17134.1_none_bcfdca399f684482.manifest
\windows\winsxs\manifests\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.17134.1_none_ac4f391e386e1e29.manifest
\windows\winsxs\manifests\x86_microsoft.windows.i..utomation.proxystub_6595b64144ccf1df_1.0.17134.1_none_d66746ec6b2f1a97.manifest
\windows\winsxs\manifests\x86_microsoft.windows.isolationautomation_6595b64144ccf1df_1.0.17134.1_none_2ceff5b90c250083.manifest
\windows\winsxs\manifests\x86_microsoft.windows.systemcompatible_6595b64144ccf1df_6.0.17134.1_none_34240ce3e16cf008.manifest
10. That's almost all of it. Overall, more files were REMOVED than added - what a surprise!

I wonder how much of this same recipe I can follow for ARM64 x86 support...which is the goal of the exercise for me here.

 

the patch that I posted is only doing exactly what was posted by OP, nothing more or less.  it is dirty and not really a proper build.  but it works somewhat for x86 support.

[armixen]

the patch that I posted is only doing exactly what was posted by OP, nothing more or less.  it is dirty and not really a proper build.  but it works somewhat for x86 support.

 

That is great to hear. I will let you know if I manage to clean this one up.