MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?

Harder than I thought
So, i'll work like a Turtle

take easy.

"SECURITY" mechanism

Administrator account would be work?

Hi,
I have read many documents about WPD and especially UMDF/KDMF.
The anomaly encountered during the installation implements many components of the architecture UMDF/KMDF.
On my test machine, the first WPD error occurs during startup when the smart card reader is detected by the PNP mechanism.
This allowed me to understand the links between the displays of "Device Manager" ( details, properties...) and the file  "SetupAPI.Dev.log".
Note: There was also a driver missing for this player.

I then became interested in the connection of my smatphone.
I took a trace procmon and stored the files SetupAPI.Dev and Ntbtlog.
Then I looked for how to reproduce this anomaly in order to confirm my idea that took slowly.
This information crossing remains the starting point for my next work with Windbg. But it will be for later.

Following the PNP detection of the smartphone, Drvinst. EXE reports an error when the device is loaded in SetupAPI.Dev.log.
There are two installation attempts and this is confirmed by the loading sequence of the drivers in Ntbtlog.
SetupAPI. Dev. log:

"[Setup online Device Install (Hardware initiated)-USBVID_0B05 & PID_7772H1AXHM02E213W93]--> > My smartphone
...
     DVI: {Core Device Install} 21:00:53.210
...
        DVI: Install Device: Starting device ' USBVID_0B05 & PID_7772H1AXHM02E213W93 '. 21:00:54.007
        DVI: Install Device: Starting device completed. 21:00:54.070
!!!     DVI: Device not started: Device has problem: 0x25 (CM_PROB_FAILED_DRIVER_ENTRY), problem status: 0xc0000034.
        DVI: Class Installer: Exit  "
Summary of ProcMon trace that shows the following sequence:
   Drvinst. exe
      Wpd_ci. dll: WpdClassInstaller-------------------> class installer
      SetupAPI. dll: SetupDiInstallDevice----------------> Install Device
      SetupAPI. dll: SetupDiSetupDeviceProperty
      Devobj. dll: DevObjSetupDeviceProperty
      Cfgmgr. dll: CM_Set_DevNode_PropertyW
      KernelBase. dll: DeviceIoControlFile
   Then
      Wpd_ci. dll: WpdClassInstaller
      SetupAPI. dll: SetupDiInstallDevice
      Devobj. dll: DevObjRestartDevices---------------->?
      Cfgmgr. dll: CM_Get_DevNode_Status
      KernelBase. dll: DeviceIoControl
   Then
      Wpd_ci. dll: WpdClassInstaller
      SetupAPI. dll: SetupDiInstallDevice
      Devobj. dll: DevObjRestartDevices
      Devrtl. dll: DevRtlWriteTextLog devrtl. dll: DevRtlWriteTextLogError----------------> LogError  "

With "net start wudfRd", I see the error:  "System error 2 has occured         The system cannot find the file specified".
But no file access visible in ProcMon.
This new ProcMon trace shows a sequence of function calls that seems to me to match the sequence when writing the error with the installation of the smartphone.

I'm fortunate enough to have IDA. Certainly for the last time in my life.
With the functions/offset provided by ProcMon and the analysis of IDA, the origin of the error could be in this part of the code in wudfRd.sys:

Code: [Select]

RdDriver::RdDriver
Call RdDriver::InitializeLpcAndConnect

And IDA brings this comment (but where does it find it?)

   UMDF Reflector is unable to connect to Service Control Manager (SCM). This is expected during boot, when SCM has not started yet. Will retry when it starts.
   Code 0xc0000034 STATUS_OBJECT_NAME_NOT_FOUND (https://msdn.microsoft.com/en-us/library/cc704588.aspx)

As this code uses a Vtable that makes it incomprehensible.
I have to use WINDBG to be able to go further.

This is still my only working hypothesis.
I have never use Windbg with a Kernel driver.
That seems to me to be very complex at the moment.
And will take a very very long time !

That seems to me to be very complex at the moment.
And will take a very very long time !

I have seen more progress in the topic than others.
slow is not problem,take your time.

=======================================

I don't know if it be related.

some drivers can't pass the signature check with drvinst.exe.

usally skip the next call check for make it work in PE.

Code: [Select]

DriverStoreNotifyCallback:
  00000001400039BE: FF 15 74 19 01 00  call        qword ptr [__imp_pSetupValidateDriverPackage]    <=== THIS CALL
  00000001400039C4: 8B D8              mov         ebx,eax
  00000001400039C6: 85 C0              test        eax,eax
  00000001400039C8: 75 08              jne         00000001400039D2
  00000001400039CA: 8B 06              mov         eax,dword ptr [rsi]
  00000001400039CC: 41 89 47 10        mov         dword ptr [r15+10h],eax
  00000001400039D0: EB 3B              jmp         0000000140003A0D
  00000001400039D2: BA 20 00 00 00     mov         edx,20h
  00000001400039D7: 89 44 24 20        mov         dword ptr [rsp+20h],eax
  00000001400039DB: 4C 8D 0D 96 26 01  lea         r9,[??_C@_0DL@BAACEHAK@Driver?5package?5failed?5signature?5@]

Hi,
Just to say that I managed to implement the debugger and put BP in WudfRd. And this confirms the API calls that triggers the 0xc0000034 error. With the vtable, it was impossible for me to identify the requested APIs.
Now I'm going to be able to look at the code a little.

Code: [Select]

fffff802 ' b0d759e0 ffe0 jmp rax {WUDFRd! WdfLpcInterface:: WdfGetProcessManagementName (fffff802 ' b0d6e880)}
 "UMDFCommunicationPortsProcessManagement"
...
fffff802 ' b0d759e0 ffe0 jmp rax {WUDFRd! WDFLPC:: Connect (fffff802 ' b0d6f460)}
Rax = 00000000c0000034

I go to bed

Hi,
I continue the investigation with WinDbg but without significant result.

• At the time of the error: the function WudfRd! WDFLPC:: Connect calls the kernel ZwAlpcConnectPort function
  And the return is: 0xc0000034. But I can't find any information on this code.
  I link it to the information of  "DEVMGMT. msc " which reports  "(code 37) object name not found ".
  I also link it to the contents of the SetupAPI. Dev. txt file that reports an error:
  "     dvi:  Install Device: Starting device completed. 21:00:55.625
  !!!  dvi:  Device not started: Device has problem: 0x25 (CM_PROB_FAILED_DRIVER_ENTRY), problem status: 0xc0000034."
• A little investigation with WinDbg and Ida
  Inserting the smartphone triggers the PNP mechanism that installs the drivers.
  Then the wudfRd. SYS driver is loaded (by whom and how?) as shown in the Procmon traces.
  And its initialization fails in  "DriverEntry".
  The call to ZwAlpcConnectPort, which returns the 0xc0000034 code, is found fairly quickly in IDA. Vtable complicates everything
• An object  "Windows ": PortName ALPC?
     fffff802`b0d759e0 WUDFRd!WdfLpcInterface::WdfGetProcessManagementName (fffff802`b0d6e880)}
        -->>> \UMDFCommunicationPorts\ProcessManagement
     Winobj. exe shows that  "UMDFCommunicationPorts" is an entry in the object tree.
     But  "ProcessManagement " does not appear. Nor in Winpe. Nor in normal Windows10....
• i also searched for a description of the LPC (old)/APLC (new). But they are rare or too complex.
  A good description on this site answers the question "What is LPC" and describes the connection logic:
  http://Https://blogs.msdn.microsoft.com/ntdebugging/2007/07/26/lpc-local-procedure-calls-part-1-architecture/
  In short, LPC/APLC is a means of communication between a client and a server.
  My hypothesis, assuming the APLC connection logic is identical to that of LPC:
     in the case of WPD, and after inserting the smartphone into the USB socket of the PC:
        The PNP mechanism loads the drivers winusb.sys and WUDFRD.sys
        The driver WudfRd.sys connects to a port already created by a server (Which?)
  
  The client/server connection logic in ALPC is read in AllAboutTheRPCLRPCALPCandLPCinYourPC. PDF:
  (video : http://www.securitytube.net/video/10182)
     ALPC Server calls NtAlpcCreatePort
        o Specifies port name, attributes (such as maximum message length), and security descriptor (who is allowed to open a handle to the port)
        o Server receives an “ALPC Server Connection Port” object handle
     ALPC server calls NtAlpcSendWaitReceivePort
        o Can now receive incoming connection requests (LPC_CONNECTION_REQUEST)
        o Blocking call – unless asynchronous operation is used (TBD)
     ALPC client calls NtAlpcConnectPort
        o Specifies server port name, attributes, and an optional “connection message”
     ALPC server wakes up…
  The WinDbg script to list ALPC: http://www.zer0mem.sk/?p=542
  

I do not know what is this server. The name of the port is passed as a parameter seems to be :
   "\UMDFCommunicationPorts\ProcessManagement"

Note: the wdf01000. SYS driver is loaded very early when the PC starts.

How to investigate in APLC?
How to find the server that should respond to WudfRd?
I will continue to follow the calls that precede the error with WinDbg but it's long.
Nothing Wonderful for tonight   

Hi,
About WDP/MTP :
With Windbg, I continued to walk in the code....
I have located the function that generates the error code C0000034: NT! ObpLookupObjectName
I place here some information for future use.
Segment/offset differ at each boot.

The stack before the error:

# Child-SP          RetAddr           Call Site
00 ffffef02`736b4450 fffff803`d4fad4d6 nt!ObReferenceObjectByName+0x10a
01 ffffef02`736b4720 fffff803`d4fac8bf nt!AlpcpCreateClientPort+0x76
02 ffffef02`736b47c0 fffff803`d4fac322 nt!AlpcpConnectPort+0x257
03 ffffef02`736b4940 fffff803`d4c07553 nt!NtAlpcConnectPort+0x6e
04 ffffef02`736b49c0 fffff803`d4bff370 nt!KiSystemServiceCopyEnd+0x13
05 ffffef02`736b4bc8 fffff800`3f63533a nt!KiServiceLinkage
06 ffffef02`736b4bd0 fffff800`3f6329c9 WUDFRd!WdfLpcCorePortInterface::Connect+0xfa [minkernel\wdf\framework\umdf\common\lpccoreclient\lpccore.cpp @ 298]
07 ffffef02`736b4d10 fffff800`3f62f583 WUDFRd!WdfLpcCommPort::WdfLpcCommPort+0x549 [minkernel\wdf\framework\umdf\common\lpc\lpccomm.cpp @ 172]
08 ffffef02`736b4dd0 fffff800`3f62f4c8 WUDFRd!WdfObjectList<WdfLpcCommPort,WdfLpcCommPortParameters>::CreateNew+0x4f [minkernel\wdf\framework\umdf\common\inc\clientserver\object.hpp @ 755]
09 (Inline Function) --------`-------- WUDFRd!WdfLpc::Connect+0x3e [minkernel\wdf\framework\umdf\common\lpc\lpc.cpp @ 533]
0a ffffef02`736b4e00 fffff800`3f63897b WUDFRd!WdfLpc::Connect+0x68 [minkernel\wdf\framework\umdf\common\lpc\lpc.cpp @ 517]
0b ffffef02`736b4e90 fffff800`3f629183 WUDFRd!RdDriver::InitializeLpcAndConnect+0x23b [minkernel\wdf\framework\umdf\redirector\driver\driver.cpp @ 972]
0c ffffef02`736b4f30 fffff800`3f662235 WUDFRd!RdDriver::RdDriver+0x54b [minkernel\wdf\framework\umdf\redirector\driver\driverpnp.cpp @ 404]
0d ffffef02`736b5140 fffff800`3f627039 WUDFRd!DriverEntry+0x1b5 [minkernel\wdf\framework\umdf\redirector\driver\driverpnp.cpp @ 147]
0e ffffef02`736b5310 fffff803`d4efa57a WUDFRd!FxDriverEntryWorker+0xb9 [d:\th\minkernel\wdf\framework\kmdf\src\dynamic\stub\stub.cpp @ 325]
0f ffffef02`736b5340 fffff803`d4efcc8b nt!IopLoadDriver+0x4da
10 ffffef02`736b5510 fffff803`d4efd2a8 nt!PipCallDriverAddDeviceQueryRoutine+0x1b3
11 ffffef02`736b55a0 fffff803`d4f00009 nt!PnpCallDriverQueryServiceHelper+0xcc
12 ffffef02`736b5650 fffff803`d4f098b8 nt!PipCallDriverAddDevice+0x385
13 ffffef02`736b57f0 fffff803`d4ee53cf nt!PipProcessDevNodeTree+0x164
14 ffffef02`736b5a70 fffff803`d4bb077a nt!PiRestartDevice+0xa7
15 ffffef02`736b5ac0 fffff803`d4ad4e05 nt!PnpDeviceActionWorker+0x43a
16 ffffef02`736b5b80 fffff803`d4ac0f87 nt!ExpWorkerThread+0xf5
17 ffffef02`736b5c10 fffff803`d4c01676 nt!PspSystemThreadStartup+0x47
18 ffffef02`736b5c60 00000000`00000000 nt!KiStartSystemThread+0x16

the function "nt!ObReferenceObjectByName" calls "nt!ObpLookupObjectName".
And in the case of winpe, "nt!ObpLookupObjectName" tests :
fffff803`d4f9adea 4c8badf8000000  mov     r13,qword ptr [rbp+0F8h] <<<<<<<<<<<<<<<<<<<<<< [rbp+0F8h] ???
fffff803`d4f9adf1 4d85ed          test    r13,r13
fffff803`d4f9adf4 0f8572070000    jne     nt!ObpLookupObjectName+0x119c (fffff803`d4f9b56c)
fffff803`d4f9adfa bf340000c0      mov     edi,0C0000034h  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< !!!!!!!!!!!!!!

Very naively, I would do the test to change this memory box. To see...tomorrow.

I know you are probably way farther than this but I just noticed this post by Chris a while back for MTP

http://theoven.org/index.php?topic=2229.msg24141#msg24141

when we were taking peeks at it...

I have to admit, I haven't jumped in yet.  I do not have a device I can test on, I use iPhone.. I do hope this feature eventually gets figured out it would be useful...

Hi bob.omb,

I am very happy and honored by your interest in my investigations.
Thanks for the link I did not know.
This is a game for me. No matter what the final utility is. I play with WinDbg on the one hand. And on the other hand I discover WDF (KDMF/umdf) and MPT that I do not know.
Without Android, you can use the WDF(Kmdf/Umdf) framework if your pc own a sd card reader. In Winpe, you need to put the driver for the reader. And after, WDF framework will be loaded. I wrote a little bit about this before...

In the Full-flat version of my winpe, all files and keys are present. If PNP detect a hard, then driver is loaded. The big avantage of Full-flat for investigation (not for working at office). As i wrote before :
Loading the wdf01000 framework drivers is visible in the log file "SetupAPI.dev".
The error 0xC0000034 is visible with procmon and with windbg.

Some new informations...
By realizing the first comparisons in a normal Windows 10, I realize that I have been mistaken since my first observation.
I was deceived by the display of winobj. exe.  The reality is quite different from this display.

Note: WinDbg is launched using the menu  "Kernel\local" as shown in the prompt  "lkd>".

In a normal WINDOWS10:
  WinObj (administrator mode) does not display anything under tree structure "UMDFCommunicationPorts".
I don't know why ( access may be prohibited since access to properties is ).
  Now, the command  "! Object UMDFCommunicationPorts" in Windbg displays:

lkd> !object \UMDFCommunicationPorts
Object: ffffda0c51572920  Type: (ffffb08adc6cef20) Directory
    ObjectHeader: ffffda0c515728f0 (new version)
    HandleCount: 0  PointerCount: 3
    Directory Object: ffffda0c51016920  Name: UMDFCommunicationPorts
    Hash Address          Type                      Name
    ---- -------          ----                      ----
     30  ffffb08ae110c9c0 ALPC Port                 ProcessManagement
     33  ffffda0c543ec990 Directory                 WUDF

The entry  "\UMDFCommunicationPorts\WUDF" contains the following elements:

lkd> !object \UMDFCommunicationPorts\WUDF
Object: ffffda0c543ec990  Type: (ffffb08adc6cef20) Directory
    ObjectHeader: ffffda0c543ec960 (new version)
    HandleCount: 1  PointerCount: 6
    Directory Object: ffffda0c51572920  Name: WUDF

    Hash Address          Type                      Name
    ---- -------          ----                      ----
     14  ffffb08ae1368bd0 ALPC Port                 HostProcess-4004d68e-eb65-411f-93f3-267b08b3520f
     23  ffffb08adfa09480 ALPC Port                 HostProcess-bdd92219-ec86-42cc-883e-0cc50d9087b6
         ffffb08ade853bf0 ALPC Port                 HostProcess-68734194-bb9e-4805-bcb6-4c35e12b3f92
     35  ffffb08adf64ee20 ALPC Port                 HostProcess-25da0260-f878-4fe9-afad-dcb47f989a08

All addresses point to  "WUDFHost. exe" :

lkd> !object ffffb08ae1368bd0
Object: ffffb08ae1368bd0  Type: (ffffb08adc768f20) ALPC Port
    ObjectHeader: ffffb08ae1368ba0 (new version)
    HandleCount: 1  PointerCount: 32756
    Directory Object: ffffda0c543ec990  Name: HostProcess-4004d68e-eb65-411f-93f3-267b08b3520f
lkd> !findhandle ffffb08ae1368bd0
***NO HANDLES IN PROCESS ffffb08ae0d3b080***                                                             
                   [ffffb08adf631080 WUDFHost.exe]
   200: Entry ffffda0c56d34800 Granted Access 1f0001 (Inherit)

The case of  "\UMDFCommunicationPorts\ProcessManagement" is even more interesting:

lkd> !object ffffb08ae110c9c0
Object: ffffb08ae110c9c0  Type: (ffffb08adc768f20) ALPC Port
    ObjectHeader: ffffb08ae110c990 (new version)
    HandleCount: 1  PointerCount: 32710
    Directory Object: ffffda0c51572920  Name: ProcessManagement
lkd> !findhandle ffffb08ae110c9c0
***NO HANDLES IN PROCESS ffffb08ae0d3b080***                                                             
                   [ffffb08ae0dba080 services.exe]
   1ec: Entry ffffda0c542e67b0 Granted Access 1f0001 (Protected)

lkd> !alpc /p ffffb08ae110c9c0
Port  ffffb08ae110c9c0
  Type                      : ALPC_CONNECTION_PORT
  CommunicationInfo         : ffffda0c5440a520
    ConnectionPort          : ffffb08ae110c9c0 (ProcessManagement)
    ClientCommunicationPort : 0000000000000000
    ServerCommunicationPort : 0000000000000000
  OwnerProcess              : ffffb08ae0dba080 (services.exe)
  SequenceNo                : 0x00000005 (5)
  CompletionPort            : 0000000000000000
  CompletionList            : 0000000000000000
  ConnectionPending         : No
  ConnectionRefused         : No
  Disconnected              : No
  Closed                    : No
  FlushOnClose              : Yes
  ReturnExtendedInfo        : No
  Waitable                  : Yes
  Security                  : Static
  Wow64CompletionList       : No
  Main queue is empty.
  Direct message queue is empty.
  Large message queue is empty.
  Pending queue is empty.
  Canceled queue is empty.

In winpe : only "\UMDFCommunicationPorts"

Which means I wasn't looking at the right place
My new orientation:
WudfRd cannot get in touch with the server  "\UMDFCommunicationPorts\ProcessManagement".
This is not a WudfRd error.
But it is the server that did not create the object that WudfRd search.
We know that several services do not start if SystemSetupInProgress = 1. So, perhaps some thing loke thet for WDF.

How to find the driver that creates the object "\UMDFCommunicationPorts\ProcessManagement"?
An idea?

hi,
With spring and summer, i make a very big break.
After,  i'll play with WDF/WPD.
See you later.

hi,
One word before you leave....
I do not describe the research that allowed me to go from wdfRd. SYS to  "services.exe" : too long !

A summary of my findings (not to forget and before going on a trip):

I wasted a lot of time reading docunments on WDF, on the "ALPC Port", as well as analyzing code with WinDbg and Ida.
But I didn't know where to look or what to look for.

Today I sought to make new findings with depends. exe which shows:
    "Services. exe " uses  "WUDFPlatform. dll" which exports some APIs and uses NtCreateAlpcPort ...

My observation in my Winpe with two important points:
1-the command line of  "services. exe":
       CommandLine: ' X:\windows\system32\services.exe -Setup '
2-The DLL  "WUDFPlatform. dll " is absent in the space of  "services. exe"

I infer that the origin of all the impossibilities relating to WPD/MPT could come from this command line.

This opens up new avenues of investigation!

The sequel: It will be for much later. Yes, I'm advancing like a turtle 

Hi,
I try your ps scripts but i stack at the very first step!
See attached icon

Hi dpap,
Sorry for the delay.

I never took the time to get the PS to deal with 3 possible sources containing the decompressed files "install.wim"

So you have to unzip the "install.wim file" version you want in a directory on a hard drive. And you must use/give this unzip path.
As a result, the button will be active.

I'm leaving for a long journey, one or two months. I did not update to the latest version of W10 (V1803).

I'll be happy to get your opinion. You can write me on my e-mail noelblanc.winpe (at) free.fr or by PM.
My contribution aims to describe how to add self even features in winpe. It is a documentary and educational purpose.
Unfortunately, I don't want to use the language of winpe10Se. So sometimes there's an effort to do.

See you later

Hi NoelBlanc
unfortunately it didn't help.
I used the path of decompressed wim files (win10PR_SE2017-12-02\workbench\win10PESE\cache\Windows10 S_cloud_10.0.16200.15_x64_el-GR\install_wim) but the buttons still grayed!

Hi dpap,
My script tries to discover the language of the OS contained in the unzipped file corresponding to the System hive. The "Launch " button is enabled only if the language is recognized.
After mounting this hive in HKU:\tmp_ref_sys, it uses the key "...\ControlSet001\Control\MUI\UILanguages" to identify the language.
in the main Ps script :
line 317 : it defines the key for language  testing
line 693 : the test to activate (or not) the "lancement" button ($button_Excution.Enabled = $true)

Can you mount this hive (from your source) and verify the presence of this keys ? or "send/share" me "your" system hive ?

is your source a "Windows10 S" ?
"win10PR_SE2017-12-02...10.0.16200.15"
i never test them.

Please, if it is possible for you, use my email noelblanc.winpe(at)free.fr or PM

I hope my English is not too bad.

Hi,
Some news from WPD-MTP: It works for my microwinpebuilder for a month or two (I can't remember).
It only worked with the kernel debugger WINDBG: So, not practical!
Now it works automatically.

Get MTP, is not so simple as copying  "files/keys/install drivers "
When I realized that there was a lack of a ALPC port, I read many documents on ALPC port,WDF-Wumdf platform (for 3 or 4 months).
I do not remember how I understood that I had to look in  "services.EXE ". Chance probably.
PPL security hides the loading of DLLs in  "Services.EXE".
And I found that the service contains the name of the SALW port and can load  "WudfPlatform.DLL".
So I take WinDbg and go..... but I need to learn how to use the kernel debugger!
And I find that I can say to "services.EXE" to load this DLL.
After, MTP works  "directly " in my WinPE FullFlat.
Getting  "files/keys/services/drivers " for the MicroWinpeBuilder context was long but not too complex.
To get MTP without  "WINDBG ", I have two ways: to modifiy  "services. EXE  "program or to find a bypass
I tried to change the program  "Services. EXE". But the PPL security mechanism prohibits the modification of the file  "services. EXE".
On another site (why not name it? A lot of people go on both sites), I posted in order to find out if anyone knew a trick for this change.
Impossible for me.
So the workaround is to create a hook as @slore explained.

Now I find that my SmardCard drive in my WinPE does not work. And it uses WUMDF.
It doesn't work in my fullFlat context. So I think it's more complex to get it.

I will be putting scripts and PDFs up to date after Christmas holidays
I will look in January for reader SmardCard

Hi, noel

  Great thanks for researching my hard request.

YOU sent gift to me early.
Look forward to the later update.

@slore Thank you very much. And Your help was absolutely necessary for the hook. 

For a long time, the spooler and printers are working in my WinPE context.
And this morning, I finally got what I've been looking for for a long time.
- Can eject a USB device with the icon at the bottom right
- See printers in Devices and printers ( icon at the bottom right also )
It still requires a lot of work to understand and master the reproduction systematic

You can see the picture...
Hope you can put it one day in your context
Good Chrismas

I would love to get all three of these working in SE.  MTP, Printer support, and USB Ejection, Where do I start?  The PDF? There is also a way to ”Enable Feature in Source” for Print components. This may help with your projects...

I am looking at the differences between regular sources and altered sources now...

I am extracting Win10 install media v1809 to C:\Src - Also creating an empty folder C:\Test4

Then I am using the below commands (in Admin command prompt) to prepare my source with a bunch of interesting stuff (Index 10 - Pro for Workstations - to be safe for built in ReFS support)

Code: [Select]

DISM /Mount-image /imagefile:C:\src\sources\install.wim /Index:10 /MountDir:C:\Test4

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:NetFX3 /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:NetFx4Extended-ASPNET45 /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:SMB1Protocol /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:SMB1Protocol-Client /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:SMB1Protocol-Server /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:SMB1Protocol-Deprecation /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:TelnetClient /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:TFTP /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:Printing-Foundation-LPDPrintService /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:Printing-Foundation-LPRPortMonitor /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:LegacyComponents /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Image:C:\Test4 /Enable-Feature /FeatureName:Microsoft-Windows-Subsystem-Linux /All /LimitAccess /Source:C:\src\sources\sxs

DISM /Unmount-Image /MountDir:C:\Test4 /Commit

You can also use:

Code: [Select]

DISM /Image:C:\Test4 /Get-Features

To list available features in the mounted index (After using the first line above - DISM /Mount-image /imagefile:C:\src\sources\install.wim /Index:10 /MountDir:C:\Test4)

After this the features and reg keys will be baked into your install source waiting for you to pluck them out with whatever build method you choose.

**Note:
In install source after the above method mrxsmb10.sys is present in System32\Drivers @ index 10 now, with this we would have only needed to copy the file instead of the tricks we had to do... also present are .NET 3.0-3.5 files and others, as expected..  This could be an interesting addition to the projects moving forward, preparing the install media before use.  (I have a test plugin created, Chris has a copy)   Hopefully enabling the printer features in your source before build will help you get PE components working...

hi,
@bob.omb
than you for the method of construct.
i'm now in familly for the week and the celebrations ( chrismas and new year)
i'll reply in january.
I beg your pardon. Familly first.

Absolutely 

Have a great holiday!  See you in January