Jump to content











Photo
- - - - -

Adding WoW64 to WinPE 10 for 32-bit app support - V2


  • Please log in to reply
70 replies to this topic

#51 stayboogy

stayboogy

    Member

  • Members
  • 47 posts
  •  
    United States

Posted 18 December 2018 - 01:15 AM

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

:cheers:

Misty

 

 

I haven't tried this resource, but I have tried your MistyPE builders, and even though the build says there is wow64 support, it doesn't actually function for me because i constantly get side by side errors running my own x86 single exe files.

now, in my personal builds using what follows, i have working x86 support in x64 pe for most every exe i've tried.  i'm not sure what's missing in your work, maybe registry keys, i haven't really investigated since mine works fine now.

here is how i got my personal builds working--taken from info here and from diffing an oven build:

1.  first i dism add all these packages to the standard ADK x64 winpe--in this specific order, it does matter:

WinPE-WMI.cab
WinPE-WMI_en-us.cab
WinPE-NetFx.cab
WinPE-NetFx_en-us.cab
WinPE-Scripting.cab
WinPE-Scripting_en-us.cab
WinPE-PowerShell.cab
WinPE-PowerShell_en-us.cab
WinPE-StorageWMI.cab
WinPE-StorageWMI_en-us.cab
WinPE-SecureBootCmdlets.cab
WinPE-SecureStartup.cab
WinPE-SecureStartup_en-us.cab
WinPE-DismCmdlets.cab
WinPE-DismCmdlets_en-us.cab
WinPE-EnhancedStorage.cab
WinPE-EnhancedStorage_en-us.cab
WinPE-Dot3Svc.cab
WinPE-Dot3Svc_en-us.cab
WinPE-FMAPI.cab
WinPE-FontSupport-WinRE.cab
WinPE-PlatformId.cab
WinPE-WDS-Tools.cab
WinPE-WDS-Tools_en-us.cab
WinPE-WinReCfg.cab
WinPE-WinReCfg_en-us.cab
lp.cab

2.  copy all these files over the original, some are duplicates, i just let them overwrite--has to be done as "Trusted Installer" running a file explorer that is not Windows Explorer.  (some may be unnecessary, i copy and replace them anyway)

https://www.mediafir...ntents.txt/file

3.  add all these registry keys.  these all come from an Oven build with wow64 support.  in order to use these regfiles asis, you will have to mount the SOFTWARE and SYSTEM hives of the winpe under HKLM\MY_SOFTWARE and HKLM\MY_SYSTEM respectively, and as you'll see if you if open the files in a text editor.

http://www.mediafire...winsxs.reg/file
http://www.mediafire...anager.reg/file
http://www.mediafire...byside.reg/file
http://www.mediafire...32node.reg/file
http://www.mediafire...32node.reg/file

 

4. commit your changes to the wim and then dism export your new image to a clean and max compressed wim without the [DELETED] folder.

 

 

now, if you want 1803 ADK winpe with all this already done, build x64 winpe with the ADK and use my patcher here:

 

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


Edited by stayboogy, 18 December 2018 - 01:22 AM.

  • armixen likes this

#52 stayboogy

stayboogy

    Member

  • Members
  • 47 posts
  •  
    United States

Posted 18 December 2018 - 01:20 AM

I add all that not to measure dicks [jk LoL] but to offer what i've encountered, and, if someone wants to clean what I have up, remove unnecessary parts if there are any, and make proper registry files for the keys i've got which i know there are some unnecessary ones there.



#53 armixen

armixen

    Member

  • Members
  • 32 posts
  •  
    Australia

Posted 18 December 2018 - 01:23 AM

I add all that not to measure dicks [jk LoL] but to offer what i've encountered, and, if someone wants to clean what I have up, remove unnecessary parts if there are any, and make proper registry files for the keys i've got which i know there are some unnecessary ones there.

 

I'm very surprised all those packages are required - in step #1 above. Does WOW64 have so many dependencies, really? Incredible.



#54 stayboogy

stayboogy

    Member

  • Members
  • 47 posts
  •  
    United States

Posted 18 December 2018 - 01:31 AM

I'm very surprised all those packages are required - in step #1 above. Does WOW64 have so many dependencies, really? Incredible.

 

they may not be--i assure you i'm no authority on the matter, but i don't have the same issues running known working x86 apps that works in x86 pe and now my x64 pe, that i did have in others' builds.


Edited by stayboogy, 18 December 2018 - 01:33 AM.

  • armixen likes this

#55 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 18 December 2018 - 03:50 PM

...I add all that not to measure dicks [jk LoL] but to offer what i've encountered...

Hahaha. No dick measuring or offence was taken at all.
 

....I haven't tried this resource, but I have tried your MistyPE builders, and even though the build says there is wow64 support, it doesn't actually function for me because i constantly get side by side errors running my own x86 single exe files...

I'm not sure when you tested MistyPE?

Changelog -
2017.04.01 
....Bug in SysWoW64 support for Windows 8.1 fixed....
WoW64 support was improved at this time and hopefully fixed some of the issues you experienced. It would be useful to know so that I can try to fix any issues.

Everyone has their own preferred methods, and I'm not advocating that people change if they are happy with their current setup or methods. For me, the requirement of building PESE first is a deal breaker due to a number of factors that put me off using it. That is not meant as any kind of slight about PESE - I've just found it frustrating in my own personal use. Build time is one factor. That and a confusing UI that resulted in unsuccessful builds.

Have you tried ChrisR's Win10XPE as an alternative base? This looks very promising.

In regards to the number of packages (optional components) you have listed - these are unlikely to be necessary for WoW64 support. They will add support for a range of features, but will also add a lot of bloat and significantly increase the size of boot.wim, RAM requirements, and build time. Add with care - depending on what is needed. Just my own opinion. Based on my requirements for a minimal build.

:cheers:

Misty
  • armixen likes this

#56 armixen

armixen

    Member

  • Members
  • 32 posts
  •  
    Australia

Posted 21 December 2018 - 12:10 PM

Hahaha. No dick measuring or offence was taken at all.
 
I'm not sure when you tested MistyPE?

Changelog -

2017.04.01 
....Bug in SysWoW64 support for Windows 8.1 fixed....
WoW64 support was improved at this time and hopefully fixed some of the issues you experienced. It would be useful to know so that I can try to fix any issues.

Everyone has their own preferred methods, and I'm not advocating that people change if they are happy with their current setup or methods. For me, the requirement of building PESE first is a deal breaker due to a number of factors that put me off using it. That is not meant as any kind of slight about PESE - I've just found it frustrating in my own personal use. Build time is one factor. That and a confusing UI that resulted in unsuccessful builds.

Have you tried ChrisR's Win10XPE as an alternative base? This looks very promising.

In regards to the number of packages (optional components) you have listed - these are unlikely to be necessary for WoW64 support. They will add support for a range of features, but will also add a lot of bloat and significantly increase the size of boot.wim, RAM requirements, and build time. Add with care - depending on what is needed. Just my own opinion. Based on my requirements for a minimal build.

:cheers:

Misty

 

 

So Misty, do you have any plans to add arm64 support to MistyPE?



#57 stayboogy

stayboogy

    Member

  • Members
  • 47 posts
  •  
    United States

Posted 22 December 2018 - 03:54 AM

Hahaha. No dick measuring or offence was taken at all.
 
I'm not sure when you tested MistyPE?

Changelog -

2017.04.01 
....Bug in SysWoW64 support for Windows 8.1 fixed....
WoW64 support was improved at this time and hopefully fixed some of the issues you experienced. It would be useful to know so that I can try to fix any issues.

Everyone has their own preferred methods, and I'm not advocating that people change if they are happy with their current setup or methods. For me, the requirement of building PESE first is a deal breaker due to a number of factors that put me off using it. That is not meant as any kind of slight about PESE - I've just found it frustrating in my own personal use. Build time is one factor. That and a confusing UI that resulted in unsuccessful builds.

Have you tried ChrisR's Win10XPE as an alternative base? This looks very promising.

In regards to the number of packages (optional components) you have listed - these are unlikely to be necessary for WoW64 support. They will add support for a range of features, but will also add a lot of bloat and significantly increase the size of boot.wim, RAM requirements, and build time. Add with care - depending on what is needed. Just my own opinion. Based on my requirements for a minimal build.

:cheers:

Misty

 

 

I used v1803 for my source with your MIstyPE builders versions 12.26.2017 and 1.21.2018 are both past where you say there was a bug, and I know it says that source is unsupported, but, i have syswow64 working in my builds using what i posted above so...

 

something must still be missing in your build scripts because several x86 apps give me side by side errors using your builders, but working with what I've posted.



#58 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 23 December 2018 - 08:09 AM

I used v1803 for my source with your MIstyPE builders versions 12.26.2017 and 1.21.2018 are both past where you say there was a bug, and I know it says that source is unsupported, but, i have syswow64 working in my builds using what i posted above so...
 
something must still be missing in your build scripts because several x86 apps give me side by side errors using your builders, but working with what I've posted.

@stayboogy
Thanks for checking. Can you please let me know which 32-bit programs had side by side errors so that I can do some testing?

:cheers:

Misty

#59 teglafal

teglafal
  • Members
  • 4 posts
  •  
    Hungary

Posted 30 January 2019 - 08:36 AM

I haven't tried this resource, but I have tried your MistyPE builders, and even though the build says there is wow64 support, it doesn't actually function for me because i constantly get side by side errors running my own x86 single exe files.

now, in my personal builds using what follows, i have working x86 support in x64 pe for most every exe i've tried.  i'm not sure what's missing in your work, maybe registry keys, i haven't really investigated since mine works fine now.

here is how i got my personal builds working--taken from info here and from diffing an oven build:

1.  first i dism add all these packages to the standard ADK x64 winpe--in this specific order, it does matter:

WinPE-WMI.cab
WinPE-WMI_en-us.cab
WinPE-NetFx.cab
WinPE-NetFx_en-us.cab
WinPE-Scripting.cab
WinPE-Scripting_en-us.cab
WinPE-PowerShell.cab
WinPE-PowerShell_en-us.cab
WinPE-StorageWMI.cab
WinPE-StorageWMI_en-us.cab
WinPE-SecureBootCmdlets.cab
WinPE-SecureStartup.cab
WinPE-SecureStartup_en-us.cab
WinPE-DismCmdlets.cab
WinPE-DismCmdlets_en-us.cab
WinPE-EnhancedStorage.cab
WinPE-EnhancedStorage_en-us.cab
WinPE-Dot3Svc.cab
WinPE-Dot3Svc_en-us.cab
WinPE-FMAPI.cab
WinPE-FontSupport-WinRE.cab
WinPE-PlatformId.cab
WinPE-WDS-Tools.cab
WinPE-WDS-Tools_en-us.cab
WinPE-WinReCfg.cab
WinPE-WinReCfg_en-us.cab
lp.cab

2.  copy all these files over the original, some are duplicates, i just let them overwrite--has to be done as "Trusted Installer" running a file explorer that is not Windows Explorer.  (some may be unnecessary, i copy and replace them anyway)

https://www.mediafir...ntents.txt/file

3.  add all these registry keys.  these all come from an Oven build with wow64 support.  in order to use these regfiles asis, you will have to mount the SOFTWARE and SYSTEM hives of the winpe under HKLM\MY_SOFTWARE and HKLM\MY_SYSTEM respectively, and as you'll see if you if open the files in a text editor.

http://www.mediafire...winsxs.reg/file
http://www.mediafire...anager.reg/file
http://www.mediafire...byside.reg/file
http://www.mediafire...32node.reg/file
http://www.mediafire...32node.reg/file

 

4. commit your changes to the wim and then dism export your new image to a clean and max compressed wim without the [DELETED] folder.

 

 

now, if you want 1803 ADK winpe with all this already done, build x64 winpe with the ADK and use my patcher here:

 

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

 

I really appreciate Your work, with Your script is way easier to include the x86 enviroment! Nicely done.

One thing: have You tried for example the command 'ping'? Because its not working, it says its not a recognized command. I can find ping.exe both under system32 and syswow64 folder, but cannot run. Do You have any idea?



#60 slore

slore

    Member

  • Members
  • 51 posts
  •  
    China

Posted 30 January 2019 - 11:17 AM

D:\dev\wimbuilder2\Projects\WIN10XPE\00-Configures\Build\WoW64_Basic\submain.bat

@echo off


goto :main
[Main]
Title=WoW64 basic
Description=WoW64 basic
Author=ChriSR
Date=2018.10.11
HistoryNotes=Be Free to Customize
History001=add umpdc.dll for 19H1(2019.01.28, slore modified)

:main
if not "x%WB_PE_ARCH%"=="xx64" goto :EOF
if not "x%opt[build.wow64support]%"=="xtrue" goto :EOF


rem ==========update filesystem==========

set SxSArch=x86
call AddFiles %0 :end_files
goto :end_files


; WinSXS
; //- Language without fallback language should be enough for WinSxS
\Windows\WinSxS\%SxSArch%_microsoft.windows.c..-controls.resources_*_%WB_PE_LANG%*\*.*
\Windows\WinSxS\%SxSArch%_microsoft.windows.common-controls*\*.*
\Windows\WinSxS\wow64_microsoft.windows.gdiplus.systemcopy_*\*.*
\Windows\WinSxS\%SxSArch%_microsoft.windows.gdiplus_*\*.*
\Windows\WinSxS\%SxSArch%_microsoft.windows.isolationautomation_*\*.*
\Windows\WinSxS\%SxSArch%_microsoft.windows.i..utomation.proxystub_*\*.*
\Windows\WinSxS\%SxSArch%_microsoft-windows-servicingstack_*\*.*
; //-
\Windows\WinSxS\manifests\%SxSArch%_microsoft.windows.c..-controls.resources_*_%WB_PE_LANG%*.manifest
\Windows\WinSxS\Manifests\%SxSArch%_microsoft.windows.common-controls_*.manifest
\Windows\WinSxS\Manifests\wow64_microsoft.windows.gdiplus.systemcopy_*.manifest
\Windows\WinSxS\Manifests\%SxSArch%_microsoft.windows.gdiplus_*.manifest
\Windows\WinSxS\Manifests\%SxSArch%_microsoft.windows.isolationautomation_*.manifest
\Windows\WinSxS\Manifests\%SxSArch%_microsoft.windows.i..utomation.proxystub_*.manifest
\Windows\WinSxS\Manifests\%SxSArch%_microsoft.windows.systemcompatible_*.manifest
\Windows\WinSxS\Manifests\%SxSArch%_microsoft-windows-servicingstack_*.manifest


@windows\system32\
; Not required with build 16299 \Windows\System32\SetWoW64.exe(loadWoW64.exe)
wow64.dll,wow64cpu.dll,wow64win.dll,wowreg32.exe

@windows\SysWOW64\
C_*.NLS,KBD*.dll

+ver > 18300
umpdc.dll
+ver*

; comctl32.dll.mui,comdlg32.dll.mui and mlang.dll.mui exist in all Language folders
+mui(en-US,%WB_PE_LANG%)
comctl32.dll,comdlg32.dll,mlang.dll

+mui
aclui.dll,actxprxy.dll,adsldp.dll,adsldpc.dll,advapi32.dll,apphelp.dll,asycfilt.dll,atlthunk.dll,authz.dll,avifil32.dll,avrt.dll
bcrypt.dll,Bcp47Langs.dll,bcp47mrm.dll,cabinet.dll,cfgmgr32.dll,clb.dll,clip.exe,cmd.exe,cmdext.dll,combase.dll
Coremessaging.dll,CoreUIComponents.dll
crypt32.dll,cryptbase.dll,cryptdll.dll,cryptnet.dll,cryptsp.dll,cscapi.dll
d2d1.dll,d3d9.dll,d3d10warp.dll,d3d11.dll,d3d12.dll,DataExchange.dll,davhlpr.dll,dbgcore.dll,dbghelp.dll
dcomp.dll,ddraw.dll,devobj.dll,dhcpcsvc.dll,dhcpcsvc6.dll,directmanipulation.dll,dllhost.exe,dlnashext.dll,dnsapi.dll,dpapi.dll
drvstore.dll,dsrole.dll,dui70.dll,duser.dll,dwmapi.dll,Dwrite.dll,dxgi.dll,edputil.dll,ExplorerFrame.dll
FirewallAPI.dll,fltlib.dll,fwbase.dll,fwpolicyiomgr.dll,FWPUCLNT.DLL,gdi32.dll,gdi32full.dll,GdiPlus.dll,gpapi.dll,hid.dll
iertutil.dll,imm32.dll,InputHost.dll,iphlpapi.dll,kernel.appcore.dll,kernel32.dll,kernelbase.dll,linkinfo.dll,logoncli.dll
mfperfhelper.dll,mfc42.dll,mpr.dll,msacm32.dll,msacm32.drv,msasn1.dll,mscms.dll,mscories.dll,ncryptsslp.dll
msctf.dll,msi.dll,msimg32.dll,msIso.dll,mskeyprotect.dll,msls31.dll,msv1_0.dll,msvbvm60.dll,msvcp60.dll,msvcp_win.dll,msvcp110_win.dll,msvcrt.dll,msvcrt40.dll
msvfw32.dll,mswsock.dll,msxml3.dll,msxml3r.dll,msxml6.dll,msxml6r.dll,ncrypt.dll,netapi32.dll,netutils.dll,normaliz.dll,ntasn1.dll,ntdll.dll
ntdsapi.dll,ntlanman.dll,ntmarta.dll,ntshrui.dll,odbc32.dll,ole32.dll,oleacc.dll,oleaccrc.dll,oleaut32.dll,oledlg.dll,olepro32.dll
OnDemandConnRouteHelper.dll,OneCoreUAPCommonProxyStub.dll,pdh.dll,policymanager.dll,powrprof.dll,profapi.dll,propsys.dll,psapi.dll
rasadhlp.dll,rasapi32.dll,reg.exe,regedt32.exe,regsvr32.exe,riched20.dll,riched32.dll,rmclient.dll,rpcrt4.dll,rsaenh.dll
run64.exe,rundll32.exe,samcli.dll,samlib.dll,schannel.dll,sechost.dll,secur32.dll,SensApi.dll,setupapi.dll,SHCore.dll,shell32.dll
+ver <= 17700
shellstyle.dll
+ver*
shfolder.dll,shlwapi.dll,slc.dll,spfileq.dll,SPInf.dll,srvcli.dll,sspicli.dll,stdole2.tlb,stdole32.tlb,StructuredQuery.dll
svchost.exe,sxs.dll,sxsstore.dll,sxstrace.exe,TextInputFramework.dll,thumbcache.dll,twinapi.dll,twinapi.appcore.dll,tzres.dll
ulib.dll,ucrtbase.dll,UIAnimation.dll,UIAutomationCore.dll,urlmon.dll,user32.dll,userenv.dll,usp10.dll,uxtheme.dll,vbscript.dll,version.dll
webio.dll,wimgapi.dll,winbrand.dll,WindowsCodecs.dll,Windows.Globalization.dll,windows.storage.dll,wininet.dll,winmm.dll,winmmbase.dll
winnlsres.dll,winnsi.dll,winspool.drv,winsta.dll,WinTypes.dll,wintrust.dll,wkscli.dll,wldap32.dll,wow32.dll,ws2_32.dll,wsock32.dll,wtsapi32.dll,xmllite.dll

; Multimedia
AudioSes.dll,devenum.dll,dsound.dll,MMDevAPI.dll,msdmo.dll,quartz.dll

; Network
winhttp.dll

; 32 bit Web-Based Enterprise Management \Windows\SysWOW64\wbem (Optional). wmi.dll is in winre.wim
;wbem\
;wbemcomn.dll,framedynos.dll,ncobjapi.dll,wmiclnt.dll


; WB Dependencies addition
ieframe.dll,mshtml.dll
-mui

:end_files

if exist "%X%\windows\system32\imageres.dll" (
  copy /y "%X%\windows\system32\imageres.dll" "%X%\windows\syswow64\"
)

rem ==========update registry==========


rem [Reg_WoW64]
rem //RegImportFile,%ScriptDir%\WoW64_RegSoftware.txt
call RegCopy HKLM\Software\Classes\Wow6432Node\CLSID
call RegCopy HKLM\Software\Classes\Wow6432Node\Interface
::-
call RegCopy HKLM\Software\Classes\WOW6432Node\DirectShow
call RegCopy "HKLM\Tmp_Software\Classes\WOW6432Node\Media Type"
call RegCopy HKLM\Software\Classes\WOW6432Node\MediaFoundation
::-
call RegCopy HKLM\Software\Wow6432Node
::-
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SMI
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners,x86_microsoft.windows.c..-controls.resources_*
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners,x86_microsoft.windows.common-controls_*
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners,wow64_microsoft.windows.gdiplus.systemcopy_*
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners,x86_microsoft.windows.gdiplus_*
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners,x86_microsoft.windows.i..utomation.proxystub_*
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners,x86_microsoft.windows.isolationautomation_*
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners,x86_microsoft.windows.systemcompatible_*
call RegCopy HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners,x86_microsoft-windows-m..tion-isolationlayer_*


goto :EOF


rem [Reg_WoW64_Bigger_Classes]
call RegCopy HKLM\Software\Classes\Wow6432Node


rem [Reg_WoW64_Mini_Software]
call RegCopy HKLM\Software\Wow6432Node\Microsoft\CTF
call RegCopy HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Authentication
call RegCopy HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer
call RegCopy HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Themes
call RegCopy "HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Svchost"
call RegCopy "HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon"


#61 slore

slore

    Member

  • Members
  • 51 posts
  •  
    China

Posted 30 January 2019 - 11:21 AM

One thing: have You tried for example the command 'ping'? Because its not working, it says its not a recognized command. I can find ping.exe both under system32 and syswow64 folder, but cannot run. Do You have any idea?

 

cmd.exe

C:\>set PATH

to check your PATH environment. if next paths in it, it should be a recognized command.

 

Path=X:\Windows\system32;X:\Windows;X:\Windows\System32\Wbem;

 

 

reg query "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment" /v PATH


Edited by slore, 30 January 2019 - 11:31 AM.


#62 teglafal

teglafal
  • Members
  • 4 posts
  •  
    Hungary

Posted 30 January 2019 - 11:25 AM

cmd.exe

C:\>set PATH

to check your PATH environment. if next paths in it, it should be a recognized command.

 

Path=X:\Windows\system32;X:\Windows;X:\Windows\System32\Wbem;

The path looks okay, only one plus I have: X:\Windows\SysWOW64.

The weird thing is the following: The main cmd window (which calls the startnet.cmd and Pstart) can recognise all the commands like ping, regedit, taskmgr, etc. But when I simply start a new cmd window, all of those are not working, only from the very very main command window.



#63 slore

slore

    Member

  • Members
  • 51 posts
  •  
    China

Posted 30 January 2019 - 11:54 AM

The path looks okay, only one plus I have: X:\Windows\SysWOW64.

 But when I simply start a new cmd window, all of those are not working

 

first, you should not add X:\Windows\SysWOW64.

Windows will auto redirct  the "X:\Windows\System32" path to be "X:\Windows\SysWOW64" for 32bit application.

Please see the PATH in your normal x64 Windows.

 

I don't know where you start the new cmd windows, all program should be the child processes of startnet.cmd,

the program maybe have bug, or wrong setting, or startup earlier then startnet.cmd?

use Process Explorer to check it's EVIRONMENT, I think the PATH of it is not enough.



#64 teglafal

teglafal
  • Members
  • 4 posts
  •  
    Hungary

Posted 30 January 2019 - 12:04 PM

first, you should not add X:\Windows\SysWOW64.

Windows will auto redirct  the "X:\Windows\System32" path to be "X:\Windows\SysWOW64" for 32bit application.

Please see the PATH in your normal x64 Windows.

 

I don't know where you start the new cmd windows, all program should be the child processes of startnet.cmd,

the program maybe have bug, or wrong setting, or startup earlier then startnet.cmd?

use Process Explorer to check it's EVIRONMENT, I think the PATH of it is not enough.

Removed the SysWOW64 entry, but still not works.

 

Startnet.cmd calls PStart.exe, the organised list of applications are inside PStart. All the x86 apps are working fine, but when I'm opening a new cmd window (for example from Pstart, or Total Commander), the ping and the rest are not working from there, only from the very main cmd window.

 

Update: weird thing: the main command window's path is "X:\Windows\system32", but the newly opened cmd windows's is x:\windows\syswow64.

 

Update 2: The problem comes from PStart, and basically from every 32 bit application. If I open cmd from Windows's task manager or Process Explorer 64, the ping & co will work, because the cmd window will be an x64 one. BUT if I'm using an x86 application like PStart or Total Commander x86, the cmd window will be an x86 one, and that cannot recognise the ping & co...


Edited by teglafal, 30 January 2019 - 01:04 PM.


#65 maro

maro
  • Members
  • 4 posts
  •  
    New Zealand

Posted 31 January 2019 - 01:22 AM

...

Update 2: The problem comes from PStart, and basically from every 32 bit application. If I open cmd from Windows's task manager or Process Explorer 64, the ping & co will work, because the cmd window will be an x64 one. BUT if I'm using an x86 application like PStart or Total Commander x86, the cmd window will be an x86 one, and that cannot recognise the ping & co...

 

A simply answer might be, that your system does not contain the 32-bit executable file (e.g. 'ping.exe') that you want to run.

 

A bit more background to investigate that theory:

  1. The result of echo %PROCESSOR_ARCHITECTURE% will tell you what kind of environment you are in (with: 'x86' or 'amd64' the two possible responses on an Intel CPU).

    If you like me, and either a slow, or a lazy typist, then simply use set p and let your eyes (and brain) do the work in spotting the right answer (you'll see that there are other subtle different settings for variables starting with 'P').
     
  2. What any process "sees" in the 'system32' directory depends on whether it is itself a 32 or 64-bit process. Taking the example of a file, that we can safely assume to exist in both "worlds", and run:
    dir %WinDir%\system32\cmd.exe %WinDir%\syswow64\cmd.exe

    First in the ("native") x64 CMD, and then in the x86 CMD. Let us just take the fact that the 64-bit CMD reports two different file sizes as indicator that theses are two different files. The 32-bit CMD should report for both directories the same file (which should be the same size as the one that the native CMD has "seen" in 'syswow64').

    As a general rule of thumb, I typically assume that the larger file is the 64-bit one. But to by sure I would open the file in a hex viewer (e.g. the file viewer of 'TotalCMD' switched to 'Hex' view), and find pretty early in the file the start of the 'PE' header (either 'PE' as a string, or 0x50450000 as a 32-bit word). The following two bytes are to specify the 'Machine' (either 0x4c01 for x86, or 0x6486 for x64).
     
  3. If you now replace 'cmd.exe' in the command above with the one that troubles you (e.g. 'ping.exe') I'd expect that the x64 CMD reports no file in 'syswow64' and, the x86 CMD reports no file in either directory.
     
  4. I'd furthermore suggest that you run in a (native) x64 CMD (and hoping that 'find.exe' is present on your system):
    dir %WinDir%\system32\*.exe %WinDir%\syswow64\*.exe | find "File(s)"

    I'd expect, that far fewer executable files will be reported in the latter (non-native) directory, where 32-bit applications are expected to be found. The same is the case on non-PE (i.e. "properly installed") systems (e.g. at least on Win7 'bcdedit.exe' is only available as a x64 executable).

    I've also encountered that the creators of 64-bit PE systems don't pay much attention to 32-bit applications, and that 'syswow64' might be nearly empty.
     
  5. There exists a "virtual" directory called 'sysnative' only for 32-bit processes, that allows for these x86 processes to "see" the contents of the 'system32' directory. Remember from point 2 above that the file in both 'system32' and 'syswow64' appeared to be the same. That is correct as for x86 processes 'system32' gets redirected to 'syswow64'. So if you want to repeat the counting exercise from point 4 in a x86 CMD (and assuming that only a x64 'find.exe' file exists on your system) you could try:
    dir %WinDir%\sysnative\*.exe %WinDir%\syswow64\*.exe | %WinDir%\sysnative\find "File(s)"

So, if you are only interested to run 'ping' as a one-off 64-bit process from a 32-bit CMD you could "cheat" and call: %WinDir%\sysnative\ping
 

OTOH, if your system contains the proper x86 'ping.exe' in either the 'syswow64' or the 'sysnative' directory (depending whether one uses a x64 or a x86 CMD to search for it) then my explanation should at least help you in understanding your earlier reported observations.


 



#66 slore

slore

    Member

  • Members
  • 51 posts
  •  
    China

Posted 31 January 2019 - 02:31 AM

I can find ping.exe both under system32 and syswow64 folder.

in earlier reported confuse me.

 

 

if that is true, show next result.

 

startnet.cmd->PStart.exe(32bit)->cmd.exe(32bit)

C:\Windows\SysWOW64>set PATH

 

Is there C:\Windows\System32 in it?

 

if that is your miss, there is not ping.exe in SysWOW64 folder, you can use next trick to fallback C:\Windows\System32(64bit).

(maro explained)

 

startnet.cmd

set "PATH=%PATH%;%WinDir%\sysnative"

PStart.exe


Edited by slore, 31 January 2019 - 02:33 AM.


#67 stayboogy

stayboogy

    Member

  • Members
  • 47 posts
  •  
    United States

Posted 31 January 2019 - 03:00 AM

I really appreciate Your work, with Your script is way easier to include the x86 enviroment! Nicely done.

One thing: have You tried for example the command 'ping'? Because its not working, it says its not a recognized command. I can find ping.exe both under system32 and syswow64 folder, but cannot run. Do You have any idea?

 it woks in my personal builds... and mine is exactly what i've posted above with my additions, nothing more than my launcher and a few apps, but, ping works from any cmd opened, all exe's included work as far as i know...

 

you must have something wrong.

 

this was the same issue i had with every command in MistyPE and every Winbuilder PE in the past.

 

it has something to do with those terrible launchers included in my opinion, but even without using any in those builds mentioned and just using the console commands were often not found.


Edited by stayboogy, 31 January 2019 - 03:03 AM.


#68 stayboogy

stayboogy

    Member

  • Members
  • 47 posts
  •  
    United States

Posted 31 January 2019 - 03:10 AM

https://ibb.co/Krk42xf

 

@teglafal,

 

your issue is exactly why i posted my additions because they "do work" lol


Edited by stayboogy, 31 January 2019 - 03:17 AM.


#69 teglafal

teglafal
  • Members
  • 4 posts
  •  
    Hungary

Posted 31 January 2019 - 06:12 AM

https://ibb.co/Krk42xf
 
@teglafal,
 
your issue is exactly why i posted my additions because they "do work" lol

The answer is basically is what maro and I mentioned before. If You are using an x64 Windows on Your PC, You will see that if You are opening a cmd from an x64 application, or from the run window, an x64 cmd will start (since the 'call' comes from an x64 app), but if You start a new cmd from an x86 application (for example typing cmd in an x86 total commander) an x86 cmd will start. This behaviour is the same in PE, so the problem is/was that PStart is an x86 application, therefore an x86 cmd window will pop up if You call cmd from there, but since the x86 environment is not fully implemented/defined* (like maro explained), it wont work correctly. You can try it for Yourself too, not the build I have is buggy (since I guess its the same as Yours :) ), just start an x86 app and call cmd from there, and You'll see the same. Of course, if You are using an x64 launcher, the x64 cmd will run and will work properly :)
 
@maro
You are right! * Just start the cmd from the windir\sysnative environment, and the ping and the others will work aswell!


Edited by teglafal, 31 January 2019 - 06:44 AM.


#70 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14829 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 31 January 2019 - 09:40 AM

If I get the problem right :unsure:, maybe:

https://social.techn...rough-sccm.aspx

 

 

 

On one case we have to specifically run the application in 64-bit cmd which wasn’t looking possible even specifying various cmd switches in command line such as “c:\windows\system32\cmd.exe” or “c:\windows\syswow64\cmd.exe”, in both the scenarios it is executing cmd.exe*32 only as SCCM client is 32-bit, whatsoever command you use, OS will automatically redirect it to 32-bit version irrespective of path used.

But here is a way to prevent redirect of path and i.e. through using mklink:

Command to be used is mklink cmdin64.exe “c:\windows\system32\cmd.exe”

Now you can you following command lines (for example only):

mklink cmdin64.exe "c:\Windows\System32\cmd.exe"

cmdin64.exe /c "gacutil.exe" /u SPSI

cmdin64.exe /c "gacutil.exe" /i SPSI.dll

 

:duff:

Wonko



#71 sebus

sebus

    Frequent Member

  • Advanced user
  • 355 posts

Posted 02 February 2019 - 07:40 PM

And 5 years on, SCCM client is STILL 32-bit only...






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users