Jump to content











Photo
- - - - -

Audio for WinPE 10.0.14393


  • Please log in to reply
30 replies to this topic

#1 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 08 September 2016 - 03:39 AM

Hello, I am currently using a base image from WDK 2016's copype command.
The purpose of this PE is for remote desktop only. I have managed to get mstsc.exe from the Win7 SP1 working as the mstsc from 10.0.14915 is not working.

Now the issue I have been running into is the audio support. I have played around with various sources online, and WinBuilder scripts, but have yet to get audio fully working.

So far i have managed to get drivers installed, and the audio services running, however the audio is not working.

madplay gives an error, and mmsys.cpl shows no devices unless i do the following...
for %i in (*.dll) do @start /w regsvr32 /s %i
then drvload the various driver files, ks,kscaptur, ksfilter, wave, wdmaudio, wdma_usb, hdaudio, hdaudss, audioendpoint, bda, gameport, and modemcsa.

afterwards, the devices show under mmsys.cpl, however going to properties>levels is blank, and madplay is still throwing an error.

Anyone have any ideas? thank you



#2 Agent47

Agent47

    Frequent Member

  • Advanced user
  • 164 posts
  •  
    India

Posted 09 September 2016 - 04:12 PM

 

 

The purpose of this PE is for remote desktop only.

 

 

Sorry for bothering you but i am wondering why do you need audio support so badly if the intended purpose for this pe is remote desktop only ?.



#3 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 09 September 2016 - 10:28 PM

Well, I need to have Audio redirected.
Backstory, Had to get rid of a laptop, but we also use HP thin client's for work at home that runs a proprietary linux os.
I am running WIndows Server 2012 with RDS, and WDS, along with a few other services.
I use WDS to load up this PE via PXE Boot, so we can use the ThinClient, then using RDP, we connect to my server in the same room. Which works great...but no audio yet.
 

Edit: I rebuilt WinPE and can now use the mstsc from the windows 10 sources.

I have these keys copied from the install.wim...

HKLM\Software\Classes\CLSID

HKLM\Software\Microsoft\WIndows\MMDevices

HKLM\Software\Microsoft\WIndows NT\Multimedia

HKLM\Software\Microsoft\WIndows NT\Drivers32

HKLM\Software\Microsoft\WIndows NT\driver.desc

HKLM\Software\Microsoft\WIndows NT\SvcHost

HKLM\System\ControlSet001\Services\AudioEndpointBuilder

HKLM\System\ControlSet001\Services\AudioSrv

HKLM\System\ControlSet001\Services\MMCSS

 

The Audio Service starts fine.
but running FFplay returns a DirectSoundCreate Error 0x8007005
 

Next im going to try adding audiosrv/audioendp... ACLs to:

HKLM\Software\Microsoft\WIndows\MMDevices
as mentioned here.

 

 
 
 
 
 

Edited by Biatu, 09 September 2016 - 10:41 PM.


#4 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 10 September 2016 - 12:22 AM

made some progress by setting the ACLs on the MMDevices key. ffplay does not fail immediately, the FFT pops up as usual, and it shows the sound playing...but stilling getting no sound. madplay still getting error.



#5 RoyM

RoyM

    Frequent Member

  • .script developer
  • 420 posts
  • Interests:"Booting and Owning".
  •  
    United States

Posted 10 September 2016 - 01:15 AM

Hi Biatu and welcome.
can you please list audio hardware + motherboard you would like to get working.
 
Have you done the usual homework and installed audio drivers into running PE and then catch all changes.
I had some success recently with WinPE10 Builder and video drivers simply by changeing up the driver scripts.
It was Intel onboard graphics I was trying to get to work, 
First I used the supplied scripts for adding drivers, but they all required restart.
Next I installed video drivers into running PE and caught all file and registry changes.
Now I built a script to incorporate all of those registry and file changes, but it still required restart.
I had to disable the Intel Drivers/Original display.script, 
because now I was adding all the files and registry changes myself, where they belonged for my build.
I then added the driver integration script, after I ran my driver.script which solved all the problems.
 
Let me suggest a few things please:
Get this done very early in the boot process: "for %i in (*.dll) do @start /w regsvr32 /s %i"
Or capture the registry and file/folder changes with programs such as:
What Changed, Regshot/Regshot Unicode, Dependency Walker, Process Monitor, etc.
and make the necessary registry and file changes in your own script, 
so hardware is ready to rock and roll upon boot.
"WHEN" you load drivers and services during 
the boot process can make or break your hardware or OS.
 
"The Audio Service starts fine. but running FFplay returns a DirectSoundCreate Error 0x8007005"
 Question: "Have you ran DXDiag in running PE." ????
 
 If you can provide more hardware detail, perhaps I can help.
 Regards
 RoyM


#6 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 10 September 2016 - 02:20 AM

I have successfully got audio working! Here are my results.
 
[Files]

Windows\System32\audiodg.exe 
Windows\System32\AudioEndpointBuilder.dll 
Windows\System32\AudioEng.dll 
Windows\System32\AUDIOKSE.dll 
Windows\System32\AudioSes.dll 
Windows\System32\audiosrv.dll 
Windows\System32\AudioSrvPolicyManager.dll 
Windows\System32\avicap32.dll 
Windows\System32\avrt.dll 
Windows\System32\cca.dll 
Windows\System32\COLORCNV.DLL 
Windows\System32\CompPkgSup.dll 
Windows\System32\control.exe 
Windows\System32\coreaudiopolicymanagerext.dll 
Windows\System32\CPFilters.dll 
Windows\System32\d3d10warp.dll 
Windows\System32\D3D12.dll 
Windows\System32\d3d9.dll 
Windows\System32\ddraw.dll 
Windows\System32\devenum.dll 
Windows\System32\deviceaccess.dll 
Windows\System32\dinput8.dll 
Windows\System32\DolbyDecMFT.dll 
Windows\System32\dsound.dll 
Windows\System32\dxdiag.exe 
Windows\System32\dxdiagn.dll 
Windows\System32\EncDec.dll 
Windows\System32\evr.dll 
Windows\System32\ExplorerFrame.dll 
Windows\System32\hevcdecoder.dll 
Windows\System32\imaadp32.acm 
Windows\System32\ksproxy.ax 
Windows\System32\l3codeca.acm 
Windows\System32\mfAACEnc.dll 
Windows\System32\mfaudiocnv.dll 
Windows\System32\mfdvdec.dll 
Windows\System32\mfh263enc.dll 
Windows\System32\mfh264enc.dll 
Windows\System32\mfh265enc.dll 
Windows\System32\mfmjpegdec.dll 
Windows\System32\mfmpeg2srcsnk.dll 
Windows\System32\mfvdsp.dll 
Windows\System32\MFWMAAEC.DLL 
Windows\System32\mmci.dll 
Windows\System32\mmres.dll 
Windows\System32\mmsys.cpl 
Windows\System32\MP3DMOD.DLL 
Windows\System32\MP43DECD.DLL 
Windows\System32\MP4SDECD.DLL 
Windows\System32\Mpeg2Data.ax 
Windows\System32\mpg2splt.ax 
Windows\System32\MPG4DECD.DLL 
Windows\System32\MSAC3ENC.DLL 
Windows\System32\msacm32.drv 
Windows\System32\msadp32.acm 
Windows\System32\MSAlacDecoder.dll 
Windows\System32\MSAlacEncoder.dll 
Windows\System32\MSAMRNBDecoder.dll 
Windows\System32\MSAMRNBEncoder.dll 
Windows\System32\MSAudDecMFT.dll 
Windows\System32\msdmo.dll 
Windows\System32\MSDvbNP.ax 
Windows\System32\MSFlacDecoder.dll 
Windows\System32\MSFlacEncoder.dll 
Windows\System32\msg711.acm 
Windows\System32\msgsm32.acm 
Windows\System32\msmpeg2adec.dll 
Windows\System32\MSMPEG2ENC.DLL 
Windows\System32\msmpeg2vdec.dll 
Windows\System32\MSNP.ax 
Windows\System32\MSOpusDecoder.dll 
Windows\System32\msvfw32.dll 
Windows\System32\MSVideoDSP.dll 
Windows\System32\MSVP9DEC.dll 
Windows\System32\msvproc.dll 
Windows\System32\MSVPXENC.dll 
Windows\System32\ndfapi.dll 
Windows\System32\pcacli.dll 
Windows\System32\psisrndr.ax 
Windows\System32\qasf.dll 
Windows\System32\qcap.dll 
Windows\System32\qdv.dll 
Windows\System32\qdvd.dll 
Windows\System32\qedit.dll 
Windows\System32\quartz.dll 
Windows\System32\rdpendp.dll 
Windows\System32\RESAMPLEDMO.DLL 
Windows\System32\sbe.dll 
Windows\System32\spp.dll 
Windows\System32\srclient.dll 
Windows\System32\VBICodec.ax 
Windows\System32\VIDRESZR.DLL 
Windows\System32\wdmaud.drv 
Windows\System32\WMADMOD.DLL 
Windows\System32\WMADMOE.DLL 
Windows\System32\WMSPDMOD.DLL 
Windows\System32\WMSPDMOE.DLL 
Windows\System32\WMVDECOD.DLL 
Windows\System32\WMVENCOD.DLL 
Windows\System32\WMVSDECD.DLL 
Windows\System32\WMVSENCD.DLL 
Windows\System32\WMVXENCD.DLL 
Windows\System32\WSTPager.ax 
Windows\System32\en-US\audiodg.exe.mui 
Windows\System32\en-US\AudioEndpointBuilder.dll.mui 
Windows\System32\en-US\AudioSes.dll.mui 
Windows\System32\en-US\audiosrv.dll.mui 
Windows\System32\en-US\avicap32.dll.mui 
Windows\System32\en-US\avrt.dll.mui 
Windows\System32\en-US\CPFilters.dll.mui 
Windows\System32\en-US\ddraw.dll.mui 
Windows\System32\en-US\devenum.dll.mui 
Windows\System32\en-US\deviceaccess.dll.mui 
Windows\System32\en-US\dinput8.dll.mui 
Windows\System32\en-US\dsound.dll.mui 
Windows\System32\en-US\dxdiag.exe.mui 
Windows\System32\en-US\dxdiagn.dll.mui 
Windows\System32\en-US\EncDec.dll.mui 
Windows\System32\en-US\evr.dll.mui 
Windows\System32\en-US\ExplorerFrame.dll.mui 
Windows\System32\en-US\hevcdecoder.dll.mui 
Windows\System32\en-US\imaadp32.acm.mui 
Windows\System32\en-US\ksproxy.ax.mui 
Windows\System32\en-US\l3codeca.acm.mui 
Windows\System32\en-US\mfh264enc.dll.mui 
Windows\System32\en-US\mfh265enc.dll.mui 
Windows\System32\en-US\mmci.dll.mui 
Windows\System32\en-US\mmres.dll.mui 
Windows\System32\en-US\mmsys.cpl.mui 
Windows\System32\en-US\MP4SDECD.DLL.mui 
Windows\System32\en-US\msacm32.drv.mui 
Windows\System32\en-US\msadp32.acm.mui 
Windows\System32\en-US\msg711.acm.mui 
Windows\System32\en-US\msgsm32.acm.mui 
Windows\System32\en-US\MSMPEG2ENC.DLL.mui 
Windows\System32\en-US\msvfw32.dll.mui 
Windows\System32\en-US\msvproc.dll.mui 
Windows\System32\en-US\ndfapi.dll.mui 
Windows\System32\en-US\qasf.dll.mui 
Windows\System32\en-US\qcap.dll.mui 
Windows\System32\en-US\qdv.dll.mui 
Windows\System32\en-US\qdvd.dll.mui 
Windows\System32\en-US\qedit.dll.mui 
Windows\System32\en-US\quartz.dll.mui 
Windows\System32\en-US\rdpendp.dll.mui 
Windows\System32\en-US\spp.dll.mui 
Windows\System32\en-US\test.txt 
Windows\System32\en-US\wdmaud.drv.mui 
Windows\System32\en-US\WMVDECOD.DLL.mui 
Windows\System32\en-US\WMVENCOD.DLL.mui  

[Registry]

HKLM\Software\Classes
HKLM\Software\Microsoft\Multimedia
HKLM\Software\Microsoft\PolicyManager
HKLM\Software\Microsoft\SecurityManager
HKLM\Software\Microsoft\Windows\CurrentVersion\MMDevices
HKLM\Software\Microsoft\Windows NT\Multimedia
HKLM\Software\Microsoft\Windows NT\SvcHost
HKLM\Software\Microsoft\Windows NT\Drivers32
HKLM\Software\Microsoft\Windows NT\Drivers.desc
HKLM\System\ControlSet001\Services\AudioEndpointBuilder
HKLM\System\ControlSet001\Services\AudioSrv
HKLM\System\ControlSet001\Services\MMCSS
HKLM\System\ControlSet001\Control\WMI

 
[Drivers]

Windows\System32\DriverStore\FileRepository\c_apo.inf_x86_311d408887a570b3
Windows\System32\DriverStore\FileRepository\hdaudio.inf_x86_5c8bd6b5fd0a13a7
Windows\System32\DriverStore\FileRepository\hdaudss.inf_x86_4d7eb0f3c03f0170
Windows\System32\DriverStore\FileRepository\ks.inf_x86_6e800e1eef178e60
Windows\System32\DriverStore\FileRepository\kscaptur.inf_x86_b88dec3b83589cd0
Windows\System32\DriverStore\FileRepository\ksfilter.inf_x86_3ef2282232a749c3
Windows\System32\DriverStore\FileRepository\wave.inf_x86_7729ee3662c67b18
Windows\System32\DriverStore\FileRepository\wdmaudio.inf_x86_d7672c91c12f435d
Windows\System32\DriverStore\FileRepository\wdma_usb.inf_x86_fbefcf9515dd3250

[ACLs]

subinacl /subkeyreg "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\MMDevices" /grant="NT Service\Audiosrv"=f
subinacl /subkeyreg "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\MMDevices" /grant="NT Service\AudioEndpointBuilder"=f

[Init]

drvload.exe X:\Windows\System32\DriverStore\FileRepository\c_apo.inf_x86_311d408887a570b3
drvload.exe X:\Windows\System32\DriverStore\FileRepository\hdaudio.inf_x86_5c8bd6b5fd0a13a7
drvload.exe X:\Windows\System32\DriverStore\FileRepository\hdaudss.inf_x86_4d7eb0f3c03f0170
drvload.exe X:\Windows\System32\DriverStore\FileRepository\ks.inf_x86_6e800e1eef178e60
drvload.exe X:\Windows\System32\DriverStore\FileRepository\kscaptur.inf_x86_b88dec3b83589cd0
drvload.exe X:\Windows\System32\DriverStore\FileRepository\ksfilter.inf_x86_3ef2282232a749c3
drvload.exe X:\Windows\System32\DriverStore\FileRepository\wave.inf_x86_7729ee3662c67b18
drvload.exe X:\Windows\System32\DriverStore\FileRepository\wdmaudio.inf_x86_d7672c91c12f435d
drvload.exe X:\Windows\System32\DriverStore\FileRepository\wdma_usb.inf_x86_fbefcf9515dd3250
net start mmcss
net start AudioEndpointBuilder
net start AudioSrv
regsvr32 /s quartz.dll

Edited by Biatu, 10 September 2016 - 03:11 AM.

  • wimb likes this

#7 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 10 September 2016 - 03:28 AM

 

Hi Biatu and welcome.
can you please list audio hardware + motherboard you would like to get working.
 
Have you done the usual homework and installed audio drivers into running PE and then catch all changes.
I had some success recently with WinPE10 Builder and video drivers simply by changeing up the driver scripts.
It was Intel onboard graphics I was trying to get to work, 
First I used the supplied scripts for adding drivers, but they all required restart.
Next I installed video drivers into running PE and caught all file and registry changes.
Now I built a script to incorporate all of those registry and file changes, but it still required restart.
I had to disable the Intel Drivers/Original display.script, 
because now I was adding all the files and registry changes myself, where they belonged for my build.
I then added the driver integration script, after I ran my driver.script which solved all the problems.
 
Let me suggest a few things please:
Get this done very early in the boot process: "for %i in (*.dll) do @start /w regsvr32 /s %i"
Or capture the registry and file/folder changes with programs such as:
What Changed, Regshot/Regshot Unicode, Dependency Walker, Process Monitor, etc.
and make the necessary registry and file changes in your own script, 
so hardware is ready to rock and roll upon boot.
"WHEN" you load drivers and services during 
the boot process can make or break your hardware or OS.
 
"The Audio Service starts fine. but running FFplay returns a DirectSoundCreate Error 0x8007005"
 Question: "Have you ran DXDiag in running PE." ????
 
 If you can provide more hardware detail, perhaps I can help.
 Regards
 RoyM

 

 

Thanks RoyM!, didnt even think about dxdiag. But sure enough, i found a number of libraries and codec missing using procmon, now everything works like a charm. If i had any other complaint, it would be the slow video performance on RDP, but that's windows.



#8 RoyM

RoyM

    Frequent Member

  • .script developer
  • 420 posts
  • Interests:"Booting and Owning".
  •  
    United States

Posted 10 September 2016 - 04:11 PM

Congrats, Glad to (Hear) it. 

Regards

RoyM



#9 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 10 September 2016 - 07:55 PM

RoyM, I found the best way to handle dependencies, is to have a script mount a network drive to your dev folder, and while running ProcMon, filter out everything but "name not found" and under X:\Windows\system32. when something is missing, goto dev computer, run a script that will copy the file and the mui. Then from the WinPE, run a script that will copy over and regsvr32 only the added files. When all deps have been met, try running the software again. 

I found that method was much faster than" Copy a dep, rebuild image, iso, then boot into vm/pc


  • wimb likes this

#10 RoyM

RoyM

    Frequent Member

  • .script developer
  • 420 posts
  • Interests:"Booting and Owning".
  •  
    United States

Posted 11 September 2016 - 05:34 PM

Methods to help develop are always welcome.
can you please share some sample coding you used.
 
I would usually have my VM mount a shared folder
so that I could share info and files between VM and dev machine,
and then run my script/program from RAM or USB drive directly 
so that I can make changes on the fly.
once I've gotten it all working, then I will run from CD.
 
One other method/tool I just started playing with is Grub4Dos --> WIMBOOT
When I need to make changes to my build, I can make changes directly to the BOOT.WIM
and not have to rebuild.
 
Be aware that driver files are sometimes spread throughout %SystemRoot%, like %SystemRoot%\inf also.
I am curios about your [ACLs] and how you discovered that they needed to be added.
Please list your audio hardware in order to help others attempting the same.
 
P.S. One fantastic tool that I forgot to mention is RegCPE (Reg Converter PE)
This is a must have for .script developers when converting registry entries into .script 
 
Regards
RoyM


#11 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 12 September 2016 - 05:13 PM

Ok, here is my current script, i built it after the audio solution in attempt to make dll hell a breeze. its written in autoit and store on a network drive that i mount on boot.
I have install.wim extracted to \Source, and another Folder on the netdrive called \Deps.

here is what the script does...

-If procmon is running, it asks it to terminate.
-Starts up procmon with a predefined filter, and hidden in the background.

-Gets the handle of the window, then the listview of procmon.
-Next we store each new value in an array, of course excluding duplicates.
-Then after no more entires have been added, then we check those dependencies. (If the file exists in on X: ignore it, if the file does not exist in the source...again ignore it.)
-Every 200,000 events in procmon, the script clicks the button "Clear" then "Start/Stop Caputre" twice.

 

Note: The Filter Includes only "NAME NOT FOUND" and Anything under X:\Windows.
It does exclude various redundant entries like *.manifest, *.mui.DLL, etc, entries we dont really need.

So basically, you type for example mmc.exe in cmd.exe
well, since its not found, GetDeps will see that, and copy mmc.exe and mmc.exe.mui to X:\Windows\System32 and \Deps\Windows\System32.
Then you will try to run mmc again, which it will fail due to missing Dlls, which are in turn copied. Run it again!
Repeat the process until mmc.exe loads up.

The same process can be achieved with the registry entries. However, we would need to build a filter for redundant entries.

Here is the code:

#RequireAdmin
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_UseUpx=y
#AutoIt3Wrapper_Change2CUI=y
#AutoIt3Wrapper_Run_Au3Stripper=y
#Au3Stripper_Parameters=/rsln
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
#Include <WinAPIProc.au3>
#Include <Array.au3>
#include <GuiListView.au3>
#include <String.au3>
Global $sExec
Global $aDeps[0][2]
Global $sSrc=@ScriptDir&"\Source"
Global $sDep=@ScriptDir&"\Deps"

If @OSArch="X64" Then
	$sExec="ProcMon64.exe"
Else
	$sExec="ProcMon.exe"
EndIf
While ProcessExists($sExec)
	RunWait($sExec&" /terminate")
	ProcessClose($sExec)
WEnd
$iPID=Run($sExec&" /acceptEula /LoadConfig ProcmonConfiguration.pmc /Quiet",@ScriptDir,@SW_HIDE)
ProcessWait($iPID)
;ConsoleWrite("iPID="&$iPID&@CRLF)
OnAutoItExitRegister("_Exit")
Global $aWnd=_WinAPI_EnumProcessWindows($iPID,False)
If Not IsArray($aWnd) Then _Exit()
Global $hWnd
For $i=1 to $aWnd[0][0]
	If $aWnd[$i][1]="PROCMON_WINDOW_CLASS" Then
		$hWnd=$aWnd[$i][0]
	EndIf
Next
;ConsoleWrite("hWnd="&$hWnd&@CRLF)
Global $hListView=ControlGetHandle($hWnd,"","SysListView321")
;ConsoleWrite("hListView="&$hListView&@CRLF)
$iCols=_GUICtrlListView_GetColumnCount($hListView)
Local $iMax=0
Local $iLast=0
AdlibRegister("_EventWatch",250)
While Sleep(125)
	$iMax=_GUICtrlListView_GetItemCount($hListView)
	If $iMax>$iLast And $iMax>0 Then
		For $i=$iLast to $iMax
			$sExec=_GUICtrlListView_GetItemText($hListView,$i,1)
			$sPath=_GUICtrlListView_GetItemText($hListView,$i,4)
			If $sExec=@AutoItExe Then ContinueLoop
;~ 			if StringLeft($sPath,2)="HK" Then
;~ 				ConsoleWrite("[Reg] "&$sPath&@CRLF)
;~ 			EndIf
			_AddDep($sPath)
		Next
		$iLast=$iMax
		_ResolveDeps()
	EndIf
	If Not ProcessExists($iPID) Then ExitLoop
WEnd
_Exit()
Func _Exit()
	ProcessClose($iPID)
EndFunc

Func _AddDep($sPath)
	If $sPath="" Then Return False
	$sPath=StringTrimLeft($sPath,3)
	$iMax=UBound($aDeps,1)
	For $i=0 to $iMax-1
		If $aDeps[$i][0]=$sPath Then Return
	Next
	If FileExists("X:\"&$sPath) Then Return
	ReDim $aDeps[$iMax+1][2]
	$aDeps[$iMax][0]=$sPath
	$aDeps[$iMax][1]=0
	ConsoleWrite("[Chk] "&$sPath&@CRLF)
EndFunc

Func _ResolveDeps()
	$iMax=UBound($aDeps,1)
	For $i=0 to $iMax-1
		If $aDeps[$i][1]=1 Or $aDeps[$i][1]=3 Then ContinueLoop
		If FileExists("X:\"&$aDeps[$i][0]) Then
			ContinueLoop
		Else
			$sFile=StringTrimLeft($aDeps[$i][0],StringInStr($aDeps[$i][0],"\",0,-1))
			$sPath=StringTrimRight($aDeps[$i][0],StringLen($aDeps[$i][0])-StringInStr($aDeps[$i][0],"\",0,-1)+1)
			If not FileExists($sSrc&"\"&$sPath&"\"&$sFile) Then
				ConsoleWrite("[Ign] "&$aDeps[$i][0]&@CRLF)
				$aDeps[$i][1]=1
				ContinueLoop
			EndIf
			ConsoleWrite("[Cpy] "&$aDeps[$i][0]&"...")
			If FileExists($sSrc&"\"&$sPath&"\"&$sFile) Then ConsoleWrite(FileCopy($sSrc&"\"&$sPath&"\"&$sFile,"X:\"&$sPath&"\"&$sFile,1+8))
			If FileExists($sSrc&"\"&$sPath&"\en-US\"&$sFile&".mui") Then ConsoleWrite(FileCopy($sSrc&"\"&$sPath&"\en-US\"&$sFile&".mui","X:\"&$sPath&"\en-US\"&$sFile&".mui",1+8))

			If FileExists($sSrc&"\"&$sPath&"\"&$sFile) Then ConsoleWrite(FileCopy($sSrc&"\"&$sPath&"\"&$sFile,$sDep&"\"&$sPath&"\"&$sFile,1+8))
			If FileExists($sSrc&"\"&$sPath&"\en-US\"&$sFile&".mui") Then ConsoleWrite(FileCopy($sSrc&"\"&$sPath&"\en-US\"&$sFile&".mui",$sDep&"\"&$sPath&"\en-US\"&$sFile&".mui",1+8))
			ConsoleWrite(@CRLF)
			ConsoleWrite(@CRLF)
			$aDeps[$i][1]=1
		EndIf
	Next
EndFunc

Func _EventWatch()
	$iEvents=_GetEventCount()
	If $iEvents>=200000 Then
		Call("_Clear")
		_GetEventCount()
	EndIf
EndFunc

Func _GetEventCount()
	Local $iEvents=0
	$sStatus=StatusbarGetText($hWnd,"",1)
	$iEvents=StringRegExp($sStatus,"The current filter excludes all (\d{1,3}(?:,\d{1,3})?) events",1)
	If @Error Then
		$iEvents=StringRegExp($sStatus,"Showing \d{1,3}(?:,\d{1,3})? of (\d{1,3}(?:,\d{1,3})?) events",1)
		If @Error Then
			$iEvents=0
			Return $iEvents
		Else
			$iEvents=StringReplace($iEvents[0],",","")
		EndIf
	Else
		$iEvents=StringReplace($iEvents[0],",","")
	EndIf
	Return $iEvents
EndFunc

Func _Clear()
	AdlibUnRegister("_EventWatch")
	ConsoleWrite("[Inf] Clearing Events..."&@CRLF)
	ControlClick($hWnd,"","ToolbarWindow321","left",1,16*6,15)
	ControlClick($hWnd,"","ToolbarWindow321","left",1,16*8,15)
	ControlClick($hWnd,"","ToolbarWindow321","left",1,16*6,15)
	AdlibRegister("_EventWatch",250)
EndFunc

A few more notes:

-Procmon64.exe is extracted by procmon.exe in a temp dir when running on an x64 environment.

-Be sure to compile to x64 when using x64 PE/OS.
-to show the procmon window change @SW_HIDE to @SW_SHOW on line 26.


Edited by Biatu, 12 September 2016 - 05:27 PM.


#12 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 12 September 2016 - 05:22 PM

 

Methods to help develop are always welcome.
can you please share some sample coding you used.
 
I would usually have my VM mount a shared folder
so that I could share info and files between VM and dev machine,
and then run my script/program from RAM or USB drive directly 
so that I can make changes on the fly.
once I've gotten it all working, then I will run from CD.
 
One other method/tool I just started playing with is Grub4Dos --> WIMBOOT
When I need to make changes to my build, I can make changes directly to the BOOT.WIM
and not have to rebuild.
 
Be aware that driver files are sometimes spread throughout %SystemRoot%, like %SystemRoot%\inf also.
I am curios about your [ACLs] and how you discovered that they needed to be added.
Please list your audio hardware in order to help others attempting the same.
 
P.S. One fantastic tool that I forgot to mention is RegCPE (Reg Converter PE)
This is a must have for .script developers when converting registry entries into .script 
 
Regards
RoyM

 

-WIMBOOT does not seem to work on large images >~490MB
-for drivers i usually use drvload. or DISM them, then call drvload on run.
-I got the idea of modifying ACLs from this post.
-As for the device, it was HD audio.
If ur having issues finding drivers id recommend going to Drv.su, i used to rely on reboot.pro's driver packs, and the official driver packs site, but it became ill maintained, if u guys want the latest drivers goto drp.su. The crapware can be avoided, but ull have to use 7z, and do some magic to find the DP_*.7z I am kinda weary of giving away how to directly access the DP* cause i dont want them to be restricted and then nobody can get the DPs without downloading the crapware ;)



#13 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 12 September 2016 - 06:44 PM

Here is a cleaner script...
 

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Compression=4
#AutoIt3Wrapper_UseUpx=y
#AutoIt3Wrapper_Change2CUI=y
#AutoIt3Wrapper_Run_Au3Stripper=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
#cs ----------------------------------------------------------------------------

 AutoIt Version: 3.3.14.2
 Author:         BiatuAutMiahn[@outlook.com]

#ce ----------------------------------------------------------------------------
#Include <WinAPIProc.au3>
#Include <GuiListView.au3>
; Script Start - Add your code below here
Global $sExec, $aDeps[0][2], $iPID
Global $sSrc=@WorkingDir&"\Source"; Install.wim root
Global $sDep=@WorkingDir&"\Deps"; Remote cache in Dev Folder to be filtered/included in next build.
Global $sData=@ScriptDir&"\Data"; Data dir for procmon.exe

;Create Data Dirs
If Not FileExists($sSrc) Then DirCreate($sSrc)
If Not FileExists($sDep) Then DirCreate($sDep)
If Not FileExists($sData) Then DirCreate($sData)

;Set Exec based on Arch
If @OSArch="X64" Then
    $sExec="ProcMon64.exe"
Else
    $sExec="ProcMon.exe"
EndIf

;If Exec not exist, extract it.
If Not FileExists($sExec) Then
    ;FileInstall("ProcMon64.exe",$sData&"\ProcMon64.exe")
    ;FileInstall("ProcMon.exe",$sData&"\ProcMon.exe")
EndIf

;If ProcMon Running, Terminate it.
While ProcessExists($sExec)
    RunWait($sData&"\"&$sExec&" /Terminate /AcceptEula")
WEnd

;Run ProcMon.
$iPID=Run($sData&"\"&$sExec&" /acceptEula /LoadConfig ProcmonConfiguration.pmc /Quiet",$sData,@SW_HIDE)
ProcessWait($iPID)

;Get Window Handle
Global $aWnd=_WinAPI_EnumProcessWindows($iPID,False)
If Not IsArray($aWnd) Then _Exit(); If we cant get it, exit.
Global $hWnd
For $i=1 to $aWnd[0][0]
	If $aWnd[$i][1]="PROCMON_WINDOW_CLASS" Then
		$hWnd=$aWnd[$i][0]
	EndIf
Next
Global $hListView=ControlGetHandle($hWnd,"","SysListView321"); Get ListView Handle.
Local $iMax=0; Max Entries in ListView.
Local $iLast=0; Number of Entries we've captured.
AdlibRegister("_EventWatch",250) ;Check for various conditions.
While Sleep(125); every 125ms
	$iMax=_GUICtrlListView_GetItemCount($hListView)
	If $iMax>$iLast And $iMax>0 Then; if there are more items than read, and more than 0 items...
		For $i=$iLast to $iMax; Parse from the last read to the last item.
			$sExec=_GUICtrlListView_GetItemText($hListView,$i,1); Process Column.
			$sPath=_GUICtrlListView_GetItemText($hListView,$i,4); Path Column.
			If $sExec=@AutoItExe Then ContinueLoop; If The Process if our self...ignore it or else infinite loop.
			_AddDep($sPath)
		Next
		$iLast=$iMax; We have caught up
	EndIf
	If Not ProcessExists($iPID) Then ExitLoop
WEnd
;
;~ Func _ProcMon()
;~ EndFunc

Func _AddDep($spath)
    If $sPath="" Then Return; We can ignore empty data.
    If StringLeft($sPath,2)="HK" Then
        Return
    Else
        $sPath=StringTrimLeft($sPath,3); Strip the "X:" we don't care about the drive letter, just the realative path.
    EndIf
    $iMax=UBound($aDeps,1); Get the size of the Dep array/list.
	For $i=0 to $iMax-1
		If $aDeps[$i][0]=$sPath Then Return; If it already exists...ignore it.
    Next
    ReDim $aDeps[$iMax+1][2]; Extend array by 1 to fit another dep.
    $aDeps[$iMax][0]=$sPath
	$aDeps[$iMax][1]=0; 0=Unprocessed, 1=Ignore
    ;ConsoleWrite("[Chk] "&$sPath&@CRLF); Print out the name of the dep we need.

    ;Ignore if is already exists, or not available from source. Can modify later for ini exclues.
    If FileExists("X:\"&$sPath) Then Return
    If Not FileExists($sSrc&"\"&$sPath) Then
        ConsoleWrite("[Ign] "&$sPath&@CRLF)
        $aDeps[$iMax][1]=1
        Return
    EndIf
    $sFile=StringTrimLeft($sPath,StringInStr($sPath,"\",0,-1)); Get FileName.
    $sPath=StringTrimRight($sPath,StringLen($sPath)-StringInStr($sPath,"\",0,-1)+1); Get path to file.

    ConsoleWrite("[Cpy] "&$sPath&"\"&$sFile&"...")

    _CopyDep($sSrc&"\"&$sPath&"\"&$sFile,"X:\"&$sPath&"\"&$sFile);Copy to X:\...
    _CopyDep($sSrc&"\"&$sPath&"\en-US\"&$sFile&".mui","X:\"&$sPath&"\en-US\"&$sFile&".mui");Copy mui
    ;Copy to Dep Folder
    _CopyDep($sSrc&"\"&$sPath&"\"&$sFile,$sDep&"\"&$sPath&"\"&$sFile)
    _CopyDep($sSrc&"\"&$sPath&"\en-US\"&$sFile&".mui",$sDep&"\"&$sPath&"\en-US\"&$sFile&".mui")
    ConsoleWrite(@CRLF)
EndFunc

Func _CopyDep($sCpySrc,$sCpyDst)
    If FileExists($sCpySrc) Then
        If FileCopy($sCpySrc,$sCpyDst,1+8) Then
            ConsoleWrite("1")
        Else
            ConsoleWrite("0")
        EndIf
    Else
        ConsoleWrite("0")
    EndIf
EndFunc

Func _Exit()
	ProcessClose($iPID)
EndFunc

Func _EventWatch()
	$iEvents=_GetEventCount()
	If $iEvents>=200000 Then
		Call("_Clear")
		_GetEventCount()
	EndIf
EndFunc

Func _GetEventCount(); Get number of events ProcMon Captured.
	Local $iEvents=0
	$sStatus=StatusbarGetText($hWnd,"",1)
	$iEvents=StringRegExp($sStatus,"The current filter excludes all (\d{1,3}(?:,\d{1,3})?) events",1)
	If @Error Then
		$iEvents=StringRegExp($sStatus,"Showing \d{1,3}(?:,\d{1,3})? of (\d{1,3}(?:,\d{1,3})?) events",1)
		If @Error Then
			$iEvents=0
			Return $iEvents
		Else
			$iEvents=StringReplace($iEvents[0],",","")
		EndIf
	Else
		$iEvents=StringReplace($iEvents[0],",","")
	EndIf
	Return $iEvents
EndFunc

Func _Clear(); Clear ProcMon Log.
	AdlibUnRegister("_EventWatch"); Stop EventWatcher so its not called too many times.
	ConsoleWrite("[Inf] Clearing Events...")
	ControlClick($hWnd,"","ToolbarWindow321","left",1,16*6,15)
	ControlClick($hWnd,"","ToolbarWindow321","left",1,16*8,15)
	ControlClick($hWnd,"","ToolbarWindow321","left",1,16*6,15)
	AdlibRegister("_EventWatch",250)
    Dim $aDeps[0][2]
	ConsoleWrite("Done"&@CRLF&@CRLF)
EndFunc


Download here
M
oving this to a new thread later.


Edited by Biatu, 12 September 2016 - 07:05 PM.


#14 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 September 2016 - 07:07 PM

Nice. :thumbsup:

 

A question:

the \Source folder can be just a mount point to a .wim, right? (should be read-only if I get it right)

 

:duff:

Wonko



#15 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 12 September 2016 - 09:52 PM

Nice. :thumbsup:

 

A question:

the \Source folder can be just a mount point to a .wim, right? (should be read-only if I get it right)

 

:duff:

Wonko

ya..should be, script just does a file copy.



#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 September 2016 - 07:52 AM

Three things, not to clutter (yet) the "main" dedicated thread:

1) shouldn't/couldn't a line attempting to (re-)registering .dll's (as soon as they are copied to  the %SystemRoot%) be added?

2) it may be useful to have a "log-to-batch" option, i.e. something that while writing [Cpy] \Windows\System32\mmc.exe ...1111 also writes the corresponding used command to a "log" fie in such a way that once the *whatever* has been added and works there is a reproducible trace of what was done and that can be re-parsed (or using batch file or AU3 or whatever simple scripting language syntax directly) re-executed to test

3) still connected to #1, would it be useful/advisable to do for the operating system at hand a preliminary step similar to the one I used here:
http://reboot.pro/to...10-mb/?p=154017

(that proved useful in some few cases for those .dll's that have *something more* in their registration than what regsvr32 creates)?

 

:duff:

Wonko 



#17 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 13 September 2016 - 12:47 PM

Three things, not to clutter (yet) the "main" dedicated thread:

1) shouldn't/couldn't a line attempting to (re-)registering .dll's (as soon as they are copied to  the %SystemRoot%) be added?

2) it may be useful to have a "log-to-batch" option, i.e. something that while writing [Cpy] \Windows\System32\mmc.exe ...1111 also writes the corresponding used command to a "log" fie in such a way that once the *whatever* has been added and works there is a reproducible trace of what was done and that can be re-parsed (or using batch file or AU3 or whatever simple scripting language syntax directly) re-executed to test

3) still connected to #1, would it be useful/advisable to do for the operating system at hand a preliminary step similar to the one I used here:
http://reboot.pro/to...10-mb/?p=154017

(that proved useful in some few cases for those .dll's that have *something more* in their registration than what regsvr32 creates)?

 

:duff:

Wonko 

1, yes, that would be a very useful tool

2, I think Log-to-Batch would be preferred to copying the source files twice.
3, I will look into that RegDllView, as i have found myself that some dlls don't reg properly with regsvr32, like WinRAR's shell extension.

As for 1 and 2, i'll make an update later today.



#18 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 September 2016 - 01:26 PM

About #2, if you go for the "log-to-batch" approach (which should save a lot of duplicate files space on the "source" drive), a "plain" list of files involved would be anyway useful, to be able (when it is the case) "merge the results" of running the tool or - by default - it should create a "IF NOT EXIST" kind of command or use a copy tool that does not overwrite target if it exists. (and a separate list of regsvr32 commands, see below)

 

I mean, let's say that you start from a very basic PE, and you want to add program1.exe, you run the tool and find out that program1.exe has two dependencies, program1.dll and commonshared.dll :w00t:.

And you get the nice batch that allows to add program1.exe and all its dependencies.

Then, you start again from scratch, this time you want to add program2.exe that has as dependencies program2.dll and commonshared.dll.

If you re-run the two batches at build time for a new PE, the execution time will be greatly increased, as the commonshared.dll will be copied once and then overwritten by another copy of itself.

 

Same applies to the regsvr32 (or corresponding commands) it will be run n times, re-registering n-1 times the exact same and already properly registered .dll.

 

If you can do something like the above, it will be possible to have all "self-standing" apps :thumbup: (solving the - at least once common in Winbuilder projects - problem of prerequisite scripts) but at the same time avoid the added time needed for duplicates...

 

It would be a matter of pre-processing the list of files and registry commands removing duplicates, which should be much faster than actually copying files multiple times...

 

:duff:

Wonko



#19 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 13 September 2016 - 02:59 PM

About #2, if you go for the "log-to-batch" approach (which should save a lot of duplicate files space on the "source" drive), a "plain" list of files involved would be anyway useful, to be able (when it is the case) "merge the results" of running the tool or - by default - it should create a "IF NOT EXIST" kind of command or use a copy tool that does not overwrite target if it exists. (and a separate list of regsvr32 commands, see below)

 

I mean, let's say that you start from a very basic PE, and you want to add program1.exe, you run the tool and find out that program1.exe has two dependencies, program1.dll and commonshared.dll :w00t:.

And you get the nice batch that allows to add program1.exe and all its dependencies.

Then, you start again from scratch, this time you want to add program2.exe that has as dependencies program2.dll and commonshared.dll.

If you re-run the two batches at build time for a new PE, the execution time will be greatly increased, as the commonshared.dll will be copied once and then overwritten by another copy of itself.

 

Same applies to the regsvr32 (or corresponding commands) it will be run n times, re-registering n-1 times the exact same and already properly registered .dll.

 

If you can do something like the above, it will be possible to have all "self-standing" apps :thumbup: (solving the - at least once common in Winbuilder projects - problem of prerequisite scripts) but at the same time avoid the added time needed for duplicates...

 

It would be a matter of pre-processing the list of files and registry commands removing duplicates, which should be much faster than actually copying files multiple times...

 

:duff:

Wonko

Hmm, ok.
How about, by default i write a batch script that will contain a basic list, and have a subroutine in the batch script that will check if Not FIleExists, Copy, then run the regsvr32
And add an optional parameter of wether or not to output to Batch<>WBScript<>Au3

I have also considered (Not sure if I had already mentioned this), but allow GetDeps to take a "some.exe" as a parameter, and loop exec until all deps are met? Capturing all deps in a script.

But...to do that properly...I have been experimenting with the reg, whereas I modified the script to watch for needed registry keys as well. It kinda works, but slow.


Edited by Biatu, 13 September 2016 - 03:02 PM.


#20 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 September 2016 - 04:38 PM

Yep, as a matter of fact the "log" could be a sort of .inf :w00t: :ph34r: file, something containing a list of files  and of Registry keys that could be parsed by another script/exe, let's say SolveDeps.exe.

I.e.:

GetDeps.exe mmc.exe <drive><path>

makes a mmc.dep file in <drive><path>\Deps\

SolveDeps.exe <drive><path>\Deps\mmc.dep <drive><path>\Source\  

adds the mmc.exe and all dependencies and registry settings to the PE.

 

Then a third script/exe (when and if there will be time for writing it):

MergeDeps.exe <drive><path>\Deps\*.dep

might create a single "optimized" \Deps\All\merged.dep file merging all the various .dep files ...

:unsure:

 

As I see it, the issue right now is to find a "flexible enough" and "easy enough to parse" format for the file, the .inf is (IMHO) besides being partially undocumented, not suited to be written "as logged when executed", maybe it would be easier to create two log files, one related to file copy only, i.e. typically a series of:

<source> <destination> 

couples, with some special leading character like ; : or # to allow (in a manual post-processing stage) to insert notes or comments.

And another one containing the registry entries to be added (and this latter can well be directly in the form of a .reg file).

The Solvedeps would simply:

1) copy the files listed in the dep file

2) if the file just copied is a .dll run regsvr32 with it

3) if additional Registry entries are needed, merge them from the .reg file

:dubbio:

 

:duff:

Wonko


  • Biatu likes this

#21 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 13 September 2016 - 05:01 PM

Well Wonko, ur inf idea actually takes the format of an .ini consider the following...

[Modules]
Alias=Microsoft Managment Console ; < Name me later?
Exec=Windows\System32\mmc.exe
; Depends=<AnotherModule?>
;Comments

[Files]
Windows\System32\mmc.exe=1
;<RelFilePath>=0 ;  0, Ignore
                 ; +1, Copy
                 ; +2, Overrite
                 ; +4, RegSvr32
                 ;+8, RegSvr32 /i

;<RelFilePath>=6,<File Description> ; ? (6=2+4)


[Regi]
HKLM\Software\Microsoft\MMC=1
;<SrcKey>=0,1

Watcha think?
 

The overwrite flag on files should be set manually, however the RegSvr/RegSvr /i should be set as a result of the regsvr during dep copy


Edited by Biatu, 13 September 2016 - 05:11 PM.


#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 September 2016 - 08:52 AM

Sure, a .ini like the one you sketched will be fine :), and it is - partially - a form of .inf which is as a matter of fact a "special" kind of .ini complicated by "local variables" and sub-sections, and (coded) commands.

The risk of doing this is that before or later someone may find an exception of some kind that the available commands won't cover (though there are still 16/32/64/128, etc.).

Particularly the [Files] part seems to me Ok, for the [Regi] part, it would seem to me easier to list in that section only the name of the .reg file(s) to be merged to the Registry.

I believe (but may be wrong of course) that since the .reg file format is already established and working with standard tools it might be easier to deal with.

Of course if a script exists that can create such a .reg file from the [Regi] entries the practical result will be the same.

 

The idea (that needs however to be tested with the newish OS's) of using Regdllview or similar was to have something that worked both online and offline.

I mean in the minimal XP project the result is expected to be anyway "persistent" but there is a choice (or there should have been a choice) to either add something at "build time" or "install" the same something from the live system i.e. the idea is/was to have a very minimal "build" phase and then an interactive "install" phase.

 

Here, talking of a PE it could be made (should be made IMHO) both (at the choice of the user/builder) either "volatile" or "persistent".

In the case of added at build time (like just BartPE, Winbilder Projects, etc.) the *whatever* is "persistent" of course, in the case of "installed on the fly" on the live system there should be the possibility to make the addition permanent (making some backup of the Registry and added files and modifying the .wim once offline) or "volatile" by simply "installing on the fly".

 

I.e. - depending on the specific file/tool/subsystem/etc. the choice should be between adding the thingy permanently or add it only in case of necessity.

 

I believe that if the "copy related Registry entries" works, there will be no need (if not while creating the .ini and testing it) of using Regsvr32, after all with RegSvr32 does is to "collect" the Registry information from the .dll and write the corresponding entries in the Registry, we could say that .dll's that need/can be register have an embedded .reg file.

 

Talking of which - though the output is in the dreaded (by me) xml :ph34r: - maybe the heat.exe part of Wix may come useful, though the explanation is (still to me) the closest thing to Vogons' Poetry :w00t: I ever found in a program documentation:

http://wixtoolset.or...rview/heat.html

but what it can produce when analyzing harvesting a .dll seems like exactly the kind of info needed:

https://www.firegian...ifferent-color/

 

:duff:

Wonko


  • Biatu likes this

#23 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 14 September 2016 - 03:19 PM

Sure, a .ini like the one you sketched will be fine :), and it is - partially - a form of .inf which is as a matter of fact a "special" kind of .ini complicated by "local variables" and sub-sections, and (coded) commands.

The risk of doing this is that before or later someone may find an exception of some kind that the available commands won't cover (though there are still 16/32/64/128, etc.).

Particularly the [Files] part seems to me Ok, for the [Regi] part, it would seem to me easier to list in that section only the name of the .reg file(s) to be merged to the Registry.

I believe (but may be wrong of course) that since the .reg file format is already established and working with standard tools it might be easier to deal with.

Of course if a script exists that can create such a .reg file from the [Regi] entries the practical result will be the same.

 

The idea (that needs however to be tested with the newish OS's) of using Regdllview or similar was to have something that worked both online and offline.

I mean in the minimal XP project the result is expected to be anyway "persistent" but there is a choice (or there should have been a choice) to either add something at "build time" or "install" the same something from the live system i.e. the idea is/was to have a very minimal "build" phase and then an interactive "install" phase.

 

Here, talking of a PE it could be made (should be made IMHO) both (at the choice of the user/builder) either "volatile" or "persistent".

In the case of added at build time (like just BartPE, Winbilder Projects, etc.) the *whatever* is "persistent" of course, in the case of "installed on the fly" on the live system there should be the possibility to make the addition permanent (making some backup of the Registry and added files and modifying the .wim once offline) or "volatile" by simply "installing on the fly".

 

I.e. - depending on the specific file/tool/subsystem/etc. the choice should be between adding the thingy permanently or add it only in case of necessity.

 

I believe that if the "copy related Registry entries" works, there will be no need (if not while creating the .ini and testing it) of using Regsvr32, after all with RegSvr32 does is to "collect" the Registry information from the .dll and write the corresponding entries in the Registry, we could say that .dll's that need/can be register have an embedded .reg file.

 

Talking of which - though the output is in the dreaded (by me) xml :ph34r: - maybe the heat.exe part of Wix may come useful, though the explanation is (still to me) the closest thing to Vogons' Poetry :w00t: I ever found in a program documentation:

http://wixtoolset.or...rview/heat.html

but what it can produce when analyzing harvesting a .dll seems like exactly the kind of info needed:

https://www.firegian...ifferent-color/

 

:duff:

Wonko

I would prefer having multiple dep modules per dll/exe, and have them cross dependent. As for the registry entries, the .reg standard is ok, but usually contains a lot of redundant key information, it likes to create each subkey one by one, i think that should be handled internally, just create what is needed. we could implement a regshot like capture while registering the dll, however the problem with that is additional registry entries that are not spawned on regsvr32, for example, if u register mmcbase.dll, and mmcndmgr.dll, u still dont get the MMC key that references all the other snapins.

Having a fully dynamic PE has been a goal of mine for  while now, I created InfinityPE out of Win7PE_SE. I did a basic build, excluding apps, but keeping almost all included features except .Net. Afterwards i started modifying, and creating management scripts. For example, Infinity.Init.exe, Infinity.Swap.exe, Infinity.Persist.exe, Infinity.DriverManager, Infinity.ProgramManager and Infinity.SystemManager. With the system manager being a unified script of all. Anyway, on boot Init is called, and everything is setup, then tsdiscon is called to auto-logon the admin user. Swap will find a pagefile on a physical disk, and use it on boot. Persist, mounts a disk image, and is to store anything we do not want to loose on reboot. DriverManager would load/import/export drivers, and if DriverPacks were available, it would be able to parse the 7z, and index all of the INF HWIDs and descriptions, and their respective location within the DP for fast driver loading (avoid extracting 80+GB of drivers), ProgramManager would be like an apt-get for WinPE, I also had ideas for using ngrok, as a decentralized ghost network for the PE's to communicate and share resources. Another thing i was working on was live updating the image, if u had enough ram/persistent storage. Mount, make changes, reboot, or eventually Mount, commit to the image, reboot. The project is currently CodeBlocked :loleverybody: 

heat..looks abit too complicated for something like this. imho  :suda: 

The major problem with persistent features, is the file size of the image, the bigger it is the less we have to work with, eg some of these machines we work with still have 2GB or less of ram, InfintyPE always gave me trouble with less than 2GB, the image was anywhere from 500-700MB+ and most of that was just a few things I had added, like drivers. So, having a small base image, and implementing something along the lines of wimboot, where the FS is overlayed, is the preferred route imo.  :dubbio: What we really need is a Union like FS from linux for windows, something like an imdisk-proxy, where we can choose to load the image into ram.

As for updates on the GetDeps, I found a few functions for getting dll exports/imports, to prevent needless regsvr32 calls, check if the dll even exports the DllRegSrv, or DllInstall, and similar with the imports, before running regsvr32, check and see if there are any imports needed to be copied before running regsvr32. But the results are not that impressive, export checking is a major slowdown, and so is the regsvr32 itself.

I was also considering implementing a way of automatically running-rerunning the <app>.exe to get all the deps first, but A, there is no way to detect if all the return codes mean the program has crashed due to lack of deps, or not enough parameters. And B, If its a GUI app, there is no straightforward way of handling popups without a major impact to the code.



#24 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 September 2016 - 05:25 PM

Sure a working Union FS would be a godsend :), but to be fair using mountpoints and softlinks a lot of things can be done.

Using a multi-image PE was something that (although the practice did not have a lot of followers) date back the the good ol' BartPE days.

 

Though I have no idea/experience on how (if) they could work in conjunction with a .wim (which is itself a mountpoint on boot.sdi.[*] :unsure:

 

Anyway, back to topic, anything that suits you and that delivers the result is of course OK :), the recommendation/suggestion was only about making it as simple as possible.

 

:duff:

Wonko

 

[*]OT, but JFYI, in case you are not aware of its existence, the "reduced to minimum" boot.sdi by joakims saves a few bytes (useful as an example for Pxe booting on however whenever you have slow media):
http://www.msfn.org/...bootsdi/?page=1

https://github.com/jschicht/Tiny_NTFS


  • Biatu likes this

#25 Biatu

Biatu

    Member

  • Members
  • 76 posts
  •  
    United Kingdom

Posted 14 September 2016 - 05:47 PM

Sure a working Union FS would be a godsend :), but to be fair using mountpoints and softlinks a lot of things can be done.

Using a multi-image PE was something that (although the practice did not have a lot of followers) date back the the good ol' BartPE days.

 

Though I have no idea/experience on how (if) they could work in conjunction with a .wim (which is itself a mountpoint on boot.sdi.[*] :unsure:

 

Anyway, back to topic, anything that suits you and that delivers the result is of course OK :), the recommendation/suggestion was only about making it as simple as possible.

 

:duff:

Wonko

 

[*]OT, but JFYI, in case you are not aware of its existence, the "reduced to minimum" boot.sdi by joakims saves a few bytes (useful as an example for Pxe booting on however whenever you have slow media):
http://www.msfn.org/...bootsdi/?page=1

https://github.com/jschicht/Tiny_NTFS

I did try the multipart wims for InfinityPE once, like I had a layout as follows:

InfinityPE.7.32

InfinityPE.7.64

Programs.32

Programs.64

Drivers.32

Driver.64

And on the x64, just link the 32bit image to syswow64 to save space. lol never worked  :lamo: 
If im not mistaken, hardlinks/softlink conflict with FBWF, no?  :dubbio: 
I've seen that boot.sdi, useful, but i havent gotten around to using it just yet, but thanks for the tip!

One time i was working on an image, and didnt make a backup, but i happen to have another computer booted with the good copy running.
I had used a mem dump, and also used a hex editor to look for the WIM offset, then copy. image worked great...now assuming the entire wim is loaded, I believe there might be a possibility of mounting the already in memory image.  :dubbio:

 
 
 
 





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users