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

The microphone of my computers did not work in winpe but now "i can speak !" 

1-1- before anything else, you have to understand the following 2 cases:

a- The manufacturer's drivers can be used for the computer 'targeted'
about 300MB extra! Too big. I'm not testing!

b- Generic MS audio drivers can be used
I find that these generic audio drivers do not recognize the microphone built into one of my computers
I checked with WI0 "normal" by disintalating the drivers of the manufacturer and installing these generic drivers:
   -on one of my computers, fujitsu LifeBook E752:
           Built-in microphone is not recognized
           the microphone plugged into the jack jack is well recognized and operational
   -on the other computer, fujitsu LifeBook P702:
          the 2 microphones, built-in and external, work properly

   --> I realize that, in Winpe, it will not be possible to operate the built-in microphone of my E752
         This may be the case on your computer too!

   --> you must test your hardware with generics drivers if you want to know if you can use it in winpe

1-2- What worked in my Winpe V1903 and with my 2 computers

My observation: the microphone (according to the computer) works in winpe FullFlat
After a week of research, I identified this:
        By adding in winpe the CamSrv service and the few files needed: the microphone works
        files : CapabilityAccessManager.dll, CapabilityAccessManagerClient.dll

note: I read in a site that the volume level setting was not correct. I do not see that point.
For my part, the volume setting of the microphone proposed by "MMSYS. CPL" (booster/amplification, volume) satisfies me

Now I can use the microphone in Zoom with winpe...... hmmmmm....not usefull

Enjoy your bluetooth 

1- Some words about bluetooth architecture
   the MS's bluetooth stack is not the only one ( i think so ). I use only MS's stack
   "Devices" install/need OEM drivers and use many drivers of MS
   Many types of device and protocols exist : so, i can't say "all devices are OK"

2- the list of elements to add in winpe depends on the base of winpe ( i use "my" builder ) and come "after"

3- the first step : The common elements ( drivers, files, registry )
They were disponible since many weeks in my context.
But i was careful because the microphone in my bluetooth speaker didn't work in winpe although it worked in "winpe fullFlat"
Some things were not good or missing.

4 - Bluetooth and the microphone of my Sony SRS-XB10 speaker
Since I use this Bluetooth speaker, I consate that the microphone (hand free) does not work.
I thought the microphone malfunction with the generic audio drivers was related to the malfunction of the microphone in my speaker.
So I looked for both anomalies at the same time. But the two malfunctions are not related.

5- Over the course of my research around "microphone", I copied the "system\driverDataBase" keys from fullflat in winpe and "it works"
I kept looking and I identified this key change ( many weeks ! ) :
SYSTEM-DriverDatabase-DriverPackages-microsoft_bluetooth_hfp_ag.inf_amd64_5aa03f8938eb548b
SignScore - 8000000 - d000003
SYSTEM-DriverDatabase-DriverPackages-microsoft_bluetooth_hfp_hf.inf_amd64_149f09e994e553d1
SignScore - 8000000 - d000003
I don't have any information on the values of "SignerScore".
Note: I must add that I installed the bluetooth drivers in my winpe with "Dism /add-drivers". This anomaly may not appear with another method of installing pilots.

6- warnings
And so I'm not in a position to know if this solution can be suitable for other Bluetoth devices
It seems bluetooth LE devices are not paired with Win32 API

Hi noelBlanc,

thanks for sharing your research with Microphone, BlueTooth

Your posts are very nice and understanding easy. 

I will try to follow your footsteps when I can find some free time. 

Hi Lancelot
Thank you for your interest in me.

For bluetooth:
I need a little time to explain how to integrate bluetooth into a winpe
And still a little time to make a list of the various elements.
And it will take time to make a script for winbuilder.
Time for containment....

In these simple cases of investigation (without windbg...), I say "thank you" to FullFlat!
 

bonsoir noelBlanc

By adding in winpe the CamSrv service and the few files needed: the microphone works
        files : CapabilityAccessManager.dll, CapabilityAccessManagerClient.dll

this is what was the difference .... 

edit
tested with ree-sound-recorder & work 

Code: [Select]

Enjoy your bluetooth

not yet ... 

Hi,
some words about Winpe FullFlat.

The origin of "FullFlat":
I am not the originator of this environment. I am not the creator.
I use the information I found on the sites a few years ago that I do not find now.
In these sites, there was no name to describe the topic of discussion. Maybe 'ramos' but I'm not sure, it's too old.

Why the name "Winpe FullFlat"?
I haven't found a term that already exists and describes this "environment/tool."
And I wanted to use a name to differentiate this "environment/tool" from other notions that I never understood (because of my lack of skills!):
   - "RamOs" described on Chinese sites
   - "RamOs" used with WinBuilder in an "other" site.
All this led me to choose this name of "Winpe FullFlat"

What is that 'Winpe FullFlat'?
It is an environment for carrying out intestigations, researches around internal mechanisms of 'wninpe'.
It has no other use.

How is it built?
It is a complete installation of W10 "downgrade" in Winpe.
The use of a VHD allows you to benefit from the persistence of the files. And speeds up the changes.
A complete W10 installation: It's a long time! But all the files are present, the hives are complete.
The change to demote:
   I describe it with some details in the attached file but it is very easy and carries on:
      SAM, SECURITY, BCD, some files
      Software and system: a little longer but not complex

For whom?
In my opinion, the population of winpe users is divided into several families:
- users who need an efficient, fast product, adapted to their job or their need to carry out maintenance operations
- the designers of these ready-to-use "winpe", the people who develop the scripts for WinBuilder or an equivalent
- "players" with no other purpose than to want to understand how to add an absent winpe feature (often unnecessary addition)
There is no hierarchy in this classification.
This is of course the few "players" who may find a relative interest in this test environment.

What's the point for me?

- identify the complexity of a potential addition to winpe
After building a "Winpe FullFlat," I quickly see features that will work in "Winpe" or that will be "easily" added (for example, those that are banned by an indicator like "SystemSetupInProgress")
This lets you know what "energy" you will need to deploy to try to achieve an addition.
For example, answering the following question:
Is it easy to add printers, the audio microphone with the generic drivers, bluetooth (in part)?
Since these features are operational in "Winpe FullFlat," then injecting them into winpe only requires time and patience.
We will simply have to identify the right elements. But there will be no software development as for "SendMessage 05BAh" or "WPD/MTP" or "lsm" (by NyaMisty in github.com/NyaMisty/PELSMHooker)

- perform the research by comparing/cutting/moving pieces of the OS
Once you know that a feature is operational in "Winpe FullFlat," you need to look for useful items (files, registries) and add to "Winpe"
To do this, you sometimes have to copy sets of keys and files from one environment to another.
It is possible to make these copies from a Windows10. But it is difficult to do the reverse test.

Is it useful? Can't we "work" differently and use the elements (files, hives) of windows10 normal?
Yes of course. But the security environment requires more competence than mine.
I have been using this environment/investigative method for years.
It seems easier to me not to have to look at whether the impossibility of an addition comes from the contexts "METRO/UWP" or from "Winpe's special security".

Is it easy to move items between "Winpe FullFlat" and "Winpe"?
There are a lot of pitfalls. Many BSODs occur if you are not a little used to juggling "necessary" or "mortal" drivers depending on the environment.

To conclude
It was while playing with "Winpe FullFlat" that I found how to use the printers, the bluetooth (partly!), the microphone (generic MS driver on compatible hardware)

I'm not trying to convince. It's just a sharing.

Ps: I only use Sysinternals or MS software, procmon, bcdedit, dism, windbg, etc., or PS scripts written as needed

Hi, noel

I got bluetooth worked with WimBuilder2's 20 lines batch code.

I kept looking and I identified this key change ( many weeks ! ) :
SYSTEM-DriverDatabase-DriverPackages-microsoft_bluetooth_hfp_ag.inf_amd64_5aa03f8938eb548b
SignScore - 8000000 - d000003
SYSTEM-DriverDatabase-DriverPackages-microsoft_bluetooth_hfp_hf.inf_amd64_149f09e994e553d1
SignScore - 8000000 - d000003
I don't have any information on the values of "SignerScore".

As WimBuilder2 copied the install.wim's DRIVERS HIVE, It was 8000000 - d000003, so I don't do this.
I don't know why yours is different.

Bluetooth is very easy to add, as it just copy files and registry, no needs to modify some system dlls.

Thanks for sharing the information.




I just have smart phones and a Bluetooth speaker,
I can't test other devices.

@Slore : 
about  "SignerScore" : i don't copy the DRIVERS hive from ISO. So i think it's why i need that.
about BTH-LE : i can't test because i dont own this device

Last week, with FullFlat, i play with "optionalFeature.exe" and try to install "hyperV". But i can't save hives before computer is shuting down. I also add BITS to download files from the WEB. Yes, not usefull. But i like BITS because i use intensively when i worked, in my old job. Funny week !

Hi,
some words about Winpe FullFlat.

The origin of "FullFlat":

I guess:

Flat name come with none iso-wim boot 
(not inside iso or wim, It is flat)
Full when you do not use ms official WinPE (boot.wim) with explorer etc.
and If you put Flat to Ram (eg. read all .vhd to ram first with a boot manager) instead of direct disk boot, It becomes "RamOS"
If it is WinPE --> "WinPE-RamOS" or "RamOS PE"
(there was Win98 RamOS  )

In the past, It was easy to me test with FullFlat on a separate disk by using a Virtual ...
 But now I have a very low time, I quickly build and figure out what is required ...

In my opinion, the population of winpe users is divided into several families:

My Real use: I only use once or twice (or more) a year for special cases on my single PC (no need network audio etc. to my real use)
 at XP/2k3 times I was using a lot more frequently.
The rest of my interest is all curiosity at different levels. 

*
Thanks to FullFlat.7z , nice to read 

@Lancelot
I'm glad to read you. Thank you.
I add a precison for "FullFlat": it does not use winpe, changes only a few hives and files. The starting point is really a "successful" installation of w10 (16GB !).
With your explanation, I understand better what I missed with "RAMOS":

you put Flat to Ram (for example read all .vhd to ram first with a boot manager) instead of direct disk boot

I don't know how to do that. I'll look for when winter comes.
But now I'm making a big break with winpe: it's time for me to go on the roads of France with a bike

I don't know how to do that. I'll look for when winter comes.

Long Story to short check this:
https://alychitech.com/windows-xp-in-ram-memory/

+
Easier to test with NT5  no 16 GB at all 
on picture XPLite 412 MB  = XP-RamOS

+
On Gena:
- we already use "WinVBlock_0.0.1.8-Dev-20110611" to have BootDI builds (Gena inside .img) = Gena-RamOS = WinPE1-RamOS (SystemDrive is disk ;))
(same method with https://alychitech.com/windows-xp-in-ram-memory/ only Gena is PE1)
- "WinVBlock_0.0.1.8-Dev-20110611" also make simple "CreateISO" builds (Gena inside .iso) boot by loading all .iso to memory = Gena-RamOS = WinPE1-- RamOS (SystemDrive is cd ;))
both Gena-RamOS (CreateISO and BootDI) lost popularity since .wim is smaller compared to disk image (WimBoot on Gena)

Summary: It is an old story  and more info ....  but I keep short now.
I am sure https://alychitech.com/windows-xp-in-ram-memory/ will quickly give you the big picture

After NT5 ms create vhd format and add support to get windows boot from vhd
 which we were already doing with some drivers and .img with NT5 (XP/2k3) and Linux world already doing that.


+
A few years ago I had used WinNTSetup to create .vhd of Win7,
 but not for Ramos only to boot on a separate disk image,
 but It should be easy to boot all to Ram as far as I can remember ...
   The same must be valid for Win10. First check WinNTSetup tool by JFX, JFX knows a lot on this subject.

But now I'm making a big break with winpe: it's time for me to go on the roads of France with a bike

I will be after you to have a big break a few days later. 

Have a nice Summer 
 

Hello

The 20h2 version brings little new stuff, other than Edge.
note: QuickAssist.exe is ok only in the "ADM" session

To occupy these days of rain and cold, I looked why PDB symbols are not accessible on the MS servers in the "SYSTEM" session.
This anomaly forces me to implement their recovery since the ADM session (waste of time).
Procmon.exe and Windbg.exe both use dbghelp.dll APIs. Both encounter this anomaly.

It took me a long time to find a lead. I used, in addition to procmon and windbg:
- the "network" tracks with netsh,
- fiddler to track HTTPS traffic and installed its "proxy server" (good tool but i use 1% of its feature)

I make a copy/paste of the method that allowed me to find the solution.

Context for my test: Winpe 20h2 in Flat mode in a vhd

Observation:
In Winpe's System session, the symbol files (". PDB") are not accessible in the MS Symbol Server
But they have been since the Administrator session.
The 3 software tested that cannot access the HTTPS  MS Symbol Server: windbg, procmon64, symchk

First element of analysis: communication uses HTTPS protocol
The three offending programs (Windbg, Procmon64, Symchk) use Dbghelp.dll and Symsrv.dll
The Dbghelp.doc documentation (present in Windbg's directory) explains the possible course.
Symsrv.dll contains calls to HTTP API and WinInet, two different families.

First tests in the System session:
With a PS script, download a file via HTTPS: OK
With Edge: OK, visiting HTTPS sites succeeds without any problems, idem download
With "Bitsadmin.exe" /TRANSFER "test" /DOWNLOAD https://go.microsoft.com/fwlink/?linkid=2120254 "x:test"  : OK
--->>> but do these programs use winhttp.dll?
With symchk.exe: failure!!!
"X:\Debugger\symchk.exe x:\debugger\symchk.exe /s srv-https://msdl.microsoft.com/download/symbols"

Complement to be expected: Take a test by writing a piece of code in C/C++ and using WinHttp.dll

Second element of analysis:
When I take a trace with Procmon64, I find that only the WinHTTP API is requested.
With IDA, it is now easier to identify the sequence of API calls.
I activate the network trace with:
    "netsh trace start scenario-InternetClient captures-yes report-yes"
With Windbg, I observe the Symchk.exe program:
After putting breakpoints on important calls, I notice the error:0x800C2EE7   

The use of the environmental variable "set DBGHELP_LOG X:dbghelp.log" confirms this error:
"
DBGHELP: new session: Mon Dec  7 18:45:50 2020
DBGHELP: _NT_SYMBOL_PATH: srv*https://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: .;srv*https://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: srv*https://msdl.microsoft.com/download/symbols
SYMSRV:  BYINDEX: 0x1
         https://msdl.microsoft.com/download/symbols
         FLTMGR.SYS
         5510C2C86f000
SYMSRV:  UNC: X:\windows\TEMP\sym\FLTMGR.SYS\5510C2C86f000\FLTMGR.SYS - path not found
SYMSRV:  UNC: X:\windows\TEMP\sym\FLTMGR.SYS\5510C2C86f000\FLTMGR.SY_ - path not found
SYMSRV:  UNC: X:\windows\TEMP\sym\FLTMGR.SYS\5510C2C86f000\file.ptr - path not found
SYMSRV:  WinHttp interface using proxy server: none
SYMSRV:  HTTPGET: /download/symbols/index2.txt
SYMSRV:  WinHttpSendRequest: 800C2EE7 - ERROR_WINHTTP_NAME_NOT_RESOLVED
SYMSRV:  HTTPGET: /download/symbols/FLTMGR.SYS/5510C2C86f000/FLTMGR.SYS
SYMSRV:  WinHttpSendRequest: 800C2EE7 - ERROR_WINHTTP_NAME_NOT_RESOLVED
SYMSRV:  RESULT: 0x800C2EE7     
"

My first idea: use Fiddler to see https traffic between Windbg/Symchk and MS Symbol Server
Two possibilities :
use Fiddler as "Proxy Server" and install it on a PC accessible from Winpe
        Advantage: Avoid installing Fiddler on Winpe
or install Fiddler on Winpe and trace HTTPS traffic
        disadvantage: install Fiddler on Winpe

Method "use Fiddler on winpe"

- Installation of Fiddler on winpe :
        The installation program is 32bits: OK in my winpe build with my hand 
        This leads to a few surprises, including some that I had already noticed during the zoom installation:
        The app's file installation directory:
                       "X:\Windows\SysWOW64\config\systemprofile\AppData\Local\Programs\Fiddler Everywhere"   

- Fiddler configuration: you need to enable HTTPS decryption and enable "proxy server"
        https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/TrustFiddlerRootCert
        https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/MonitorRemoteMachine

- Redirecting HTTPS traffic to Fiddler's "proxy server"
        We want to trace the windbg/sysmchk traffic that uses winhttp.dll
        https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureWinHTTPApp

        "netsh winhttp set proxy 127.0.0.1:8866"

        What changes:
        HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
            ProxyEnable : dw 1
            ProxyServer : sz 127.0.0.1:8866

Now that the observation tools are in place, I can launch "symchk.exe" to acquire a symbol file.
        "X:\Debugger\symchk.exe x:\debugger\symchk.exe /s srv-https://msdl.microsoft.com/download/symbols"
And, Oh surprise, there is no error, the symbol file is actually downloaded from the MS Symbol Server.       

I've done various tests to check. It is the presence of the "proxy server" and perhaps the Certificate of Fiddler used for decoding that allows this download.
question: why and how to do without it?

Quickassist test: No Ok, so it's not the same problem
       THE HTTPS traffic visible in Fiddler contains the following channel: "This function is not supported by the system"

So I didn't make any progress.

I remember that I didn't take the time to exploit the file of the network trail "x:windows-temp-NetTrace.etl"     
The format conversion. ETL in . TXT introduces texts in the local language (Fr for me). And no need to create .TMF files   
But the main one remains understandable.
It contains:
"

• 0CD4.0D30::2020-12-09 13:33:27.883552300 [Microsoft-Windows-WebIO]0x24ADD2A8620 : =====Init Request===================
[0]0CD4.0D30::2020-12-09 13:33:27.883553300

[Microsoft-Windows-WebIO]0x24ADD2A8620 : CréerDemandeHttpWeb s’est terminé correctement. (Session 0x24ADD241980[0xFE00000020000001]) (Méthode GET) (URI https://msdl.microsoft.com/download/symbols/SymChk.pdb/F371EE66D4C70D7E1558DE921D7E36D11/SymChk.pdb) (Version 0x1.0x1) -> (Handle de demande 0xFD00000030000002)

• 0CD4.0D30::2020-12-09 13:33:27.883554900 [Microsoft-Windows-WebIO]0x24ADD2A8620 : WebSetHttpRequestInformationRoutine terminée avec succès. (Handle 0xFD00000030000002) (Indicateurs 0x80000000) (Routine d’informations 0x7FFCA6945B70) (Contexte d’informations 0x24ADD2CDA30)
[0]0708.0A2C::2020-12-09 13:33:28.288830300

[Microsoft-Windows-DNS-Client]La requête DNS a été envoyée au serveur DNS ff02::1:3 pour le nom symsrvbogusproxy et le type 1
"
Why searching "symsrvbogusproxy" in a DNS server ?

A search on the WEB gives:
https://microsoft.public.windbg.narkive.com/TPEDtmfW/using-symbol-server-symsrv-from-local-system-account
https://microsoft.public.windbg.narkive.com/rBkpB7ZF/6-6-3-5-symsrv-dll-doesn-t-work-without-using-a-winhttp-proxy-when-used-with-symproxy-dll

"Normally, symsrv uses the WinInet interface to grab symbols from the
internet. This interface provides rich support for credentialing through
proxies and protected web sites. When symsrv is run under a service, it
switches to using the WinHTTP interface. This interface does not have this
functionality. The reason for this is because normally when run from a
service, it is unmonitored by a user and sometimes it is imposible to
display UI. So hangs can occur unless I switch to the WinHTTP interface,
that does not have the same capabilities. WinHTTP is also able to run in a
multithreaded app such as the SymProxy ISAPI filter. WinInet is not able to
do this."

Of course, this is old information. But it certainly gives a lead that I don't understand yet.

The "symsrvbogusproxy" string is present in SymSrv.dll.     

If I'm going to sum it up without a mistake   --- i hope ---- :
In the "System" session  :
- in the absence of Fiddler (! ), SymSrv.dll uses WinHTTP APIs.
         But SymSrv.dll detects a "proxy server" that doesn't exist, and therefore fails.
- In the case where Fiddler's "proxy server" is present, SymSrv.dll detects this "proxy server" and therefore succeeds.

It seems to me that the key points for Winpe would be:
Which indicator generates Symsrv.dll to WinHTTP APIs?
Which indicator generates the detection of a "proxy server" that does not exist?

Search with IDA in the disassembled code...long time ....I rely on my intuition and I do the following test by adding this in winpe:

[HKEY_LOCAL_MACHINE-SOFTWARE-Microsoft-Symbol Server]
"NoInternetProxy"dword:00000001

And bingo, it works! Procmon64, SymChk now charge symbols from MS Symbols Server in System session

Now, viewing the "stack" promon menu is easier in the "system" session

Well friendly

Noel

hi,
New Goal: Added SandBox in winpe
   - inline mode with "optionalFeatures.exe"
   - offline mode with Dism

SandBox is a FOD implemented with CBS
Some concepts and technical components implemented :
   FOD - Features On demand
      Uses the same tools and techniques as OS updates
   CBS: a little-documented architecture (see the sites attached)
   Hive "Components"
   Keys HKLM-SOFTWARE-Microsoft-Windows-CurrentVersion-Component Based Servicing
   WinSxs Directory
   Keys HKLM-SOFTWARE-Microsoft-Windows-CurrentVersion-SideBySide-Winners

   Service "trustedInstall"
      TiWorker.exe
      PoQexec.exe
   WuAuServ service: allows you to pick up missing or altered items at MS

First phase: implementation of "optionalFeatures.exe" in winpe
   A long series of catches/traces with procmon allows you to find the elements to add
   It is also necessary to analyze the file "cbs.log"
   Preparing a boot.wim file
      I chose to copy the complete hive "components" of ISO in Winpe
   After many attempts/corrections, the addition of Sandbox seems to becomes possible from "optionalFeatures.exe" in winpe.
   Changes generated by CBS/TiWorker/PoqExec must now be captured

Second phase: captures changes
   Some of the changes take place before the restart.
   So we can make a backup of the 2 hives that winpe does not save
   After the restart, the changes continue.
   The pending.xml file describes these changes that the PoQexec.exe software must make.
   But the poqexec.log file reports an error at the beginning of the program.
   Failed!
   I tried to turn winpe into a win10 by changing the usual keys (the opposite of Fullflat).
   Same mistake of Poqexec
   End of search with the "online" method.
-----------------
poqexec content.log
   1d6e05a74cb568f: 0, 0, 0, 0, StartTime ;
   1d6e05a74c8f43b: 27b, c0000428, 0, 0, onecore\base\wcp\tools\poqexec\poqexec.cpp, ValidateQueuedOps(635):  ;
   1d6e05a76e3c330: 0, 0, 0, 0, EndTime ;

NTSTATUS Values c0000428 :
The hash for image %hs cannot be found in the system catalogs. The image is likely corrupt or the victim of tampering.
With IDA, i look at in the code and find :
   ValidateQueuedOps :
       call NtSetCachedSigningLevel
https://www.tiraniddo.dev/2020/02/dll-import-redirection-in-windows-10_8.html
----------------------------

Third phase: Dism "Offline"

I now have the elements that allow the installation of Sandbox "inline" with "optionalFeatures.exe"
These elements are correct for the CBS part because it is the "injection of changes" part that fails.
The idea is to add SandBox in offline mode with Dism because it avoids the activity of PoqExec.
The addition succeeds the first time : The drivers are present in the "system" hive. They were absent with the "inline" method
After the restart, I launch windowsSandbox.exe which displays the "absent hypervisor" error.

After many traces/log analysis, reading eventvwr.msc...

I come to understand that the Environment of SandBox is not complete.
IDA and Windbg allow me to find out how the hypervisor presence test is done.
It is the "CpuiId" assembler "opcode" that brings up the information of the hypervisor in the "user" mode
Too long to describe.

The question now: who sets up the CPU? And when?
It must be winload.exe. A search with notepad shows strings with "hypervisor."
And the name of a file: hvloader.dll
The addition of all HV files (with their .mui) allows us to move forward.

The launch of windowsSanbox.exe shows another error (which I didn't notice).
Eventlog reports that services and drivers have not started.
Files for these drivers are missing in "CatRoot"
The addition of these files allows us to advance a little more.

DevMgr.msc reports that 2 devices are in error
   vmbusr can't find winhvr.sys
   vpcivsp.sys cannot find winhvr.sys
Eventlog also contains information about these errors.

New question: where does this winhvr.sys driver come from?
Winhv.sys and winhvr.sys files are not associated with an entry into the hive system.
In "fr" ISO the winhv.sys file is present in the Drivers directory
So I copy winhvr.sys in the Drivers directory
New test: now errors in devmgmt.msc for the 2 "system" devices have disappeared.
But windowsSanbox.exe displays the error 0x800706d9 "There are no more End Points available from the Endpoint mapper"

I see this:

- In a normal win10 with the SandBox addition, the firewall contains rules for the "HNS" service
These rules contain an "randoming" GUID: "HNS Container Networking - DNS (UDP-In) - A0F3D698-9D26-4CB0-AAEB-0C4502720716 - 0"
They exist on a machine with HyperV without Sandbox and with other GUID of course.
And there are none in my winpe.

- With the "En-Gb" version of my winpe, eventlog displays 2 errors:
"The Hyper-V Host Compute Service service depends on the following service: Wcifs. This service might not be installed.
The Container Manager service service depends on the following service: HvHost. This service might not be installed."

New questions:
Can there be a link between the 0x800706d9 error and the firewall? Who creates these rules? And when?
Why aren't these two services created with "Dism Offline"?

Well friendly

hi,
a new step ... But something not compatible as it says in the picture.

hi, it's been a long time....
Hi,

I don't advance much in my quest for Hyper in Winpe (and not the other way around).

Also, as Winpe's start times are quite long, I tried in understanding the various origins of this delay.
Of course, finding and installing all devices takes time.
The reduction would require a selection of useful drivers. That's what WinTOGo does/did.
But what interests me a lot more is what happens in the next phase.
While loading devices (and ?), Winpe displays small dots rotating in the middle of the screen under the small window cut into 4 frames.
Then, on my old PCs, the screen stays black for about 30s.
It's this all-black screen that appeals to me. I kind of looked at why this is happening.

Reading the log files wpeinit.log and winpeshl.log gives information.
Different tests give different values but the order of magnitude is relatively constant.
I make a summary of the timeline:
   14:45:33.731, winpeshl   Beginning PNP initialization.
   14:45:33.763, winpeshl   Launching [wpeinit.exe]
   14:45:43.566, winpeshl   PNP initialization succeeded; terminating thread.
   14:45:43.660, wpeinit   No unattend file was found; WPEINIT is using default settings to initialize WinPE
   "spent 9266ms initializing removable media before unattend search"
   "spent 5062ms installing network components"
   "spent 5891ms installing network drivers"
   14:45:57.290, wpeinit   Applying WinPE unattend settings
   14:46:00.182, winpeshl   Launching [cmd.exe /c start X:\Windows\explorer.exe]
-->> Wpeinit starts when the winpeshl's PNP Thread is finished !
-->> wpeinit is very long (17or19s)
-->> the screen stays black until explorer displays the desktop.

I've been looking at how to reduce these delays and how to display a wallpaper" during these initializations.
A - first idea: the keys read by winpeshl.exe in "hklm-software-microsoft-windows nt-currentversion-winpe"
   instRoot: what use?
   CustomBackground: it seems to be talking about a wallpaper
   DisableRemovableStorageInit: what use?
   But I can't find any links on the MS doc

B - an analysis with winpeshl IDA.exe
B-a - CustomBackground: name of an image file
   If the image file exists, Winpeshl enters this new "wallpaper" in the winpe settings
   with the API  : systemParametersInfoW and parameter : SPI_SETDESKWALLPAPER 0x14
   Winpeshl.exe does nothing else with this image file
   So it is, in my opinion, wallpaperHost.exe that would display this image if it were launched!
   So this key is useless in my Winpe with "explore"
   An idea: write a piece of program that replaces a little wallpaperhost.exe and that would leave room to "Explore" then.
B-b - DisableRemovableStorageInit:
   (get from Ida) this key removes the call from WpeUtil.dll! WpeInitializeDriversOfClass
   param: GUID_DEVCLASS_1394, GUID_DEVCLASS_ENUM1394, GUID_DEVCLASS_SBP2, GUID_DEVCLASS_USB
   I used procmon to have another source of information and see a long job with ".inf"
   My idea: The search for the presence and installation of such devices takes time
   and is useful in cases I don't know about.
   My test: create this value : DisableRemovableStorageInit = -1
   The line "spent xxxxms initializing removable media before unattend search"
   no longer appears in wpeinit.log
   I checked that a USB key plugged in later is well recognized and readable

C - WinPE optional components: 3s
   The keys can be prepared during the "build": no research.

D - "Spent 5062ms installing network components"
   As I remain the only one to use "Winpe from ADK", I tell myself that I must gather all the "netcfg.exe"
   and if possible inject the information during the "build"
   Dism does not propose anything for this (if I understood everything)
   The WinRe solution integrates its network building information
   After some research, I focused on the keys:
      System-network and system-networksetup2
   My test: make a "snapshot" of these keys in my active winpe and drop them into the hive system for a next start
   Result: there is no visible gain in wpeinit.log!
        But confirm the "netcfg" are useless . Same thing by placing the associated services in ..\setup\allowstart (which avoids "net start" . So this simplifies the start-up script.
   Control: Since this data includes "network cards/interfaces", I tested this modified Winpe on my second PC: OK

E - a bug ? Drivers incompatibles with KDNIC DEBUGGER ( bcdedit /debug on )
   With the "old" drivers for my old PC ( e1c62x64.inf ) : no problem
   With the new one (net1ic64.inf) automaticaly installed by winpe :
      wpeinit (and, under, drvinst) try during 8mn (!) to install this drivers without good result
   That's the real reason I'm looking why I get a black screen for so long.

Conclusion:
   Visually, I don't see any improvement in start-up time.
   The start-up script is simpler
   The build script is bigger

Note: Winpeshl debug mode.exe
   winpeshl.exe offers 2 command-launch control logics:
   If winpeshl.ini is present:
      The launch of orders is not switchable
      I did not check if "startnet.cmd" is launched
   If winpeshl.ini is absent:
      a "debug" mode is possible by pressing the CTRL button
         it then launches "cmd.exe"
      without tying to CTRL, it launches the first order in the following order:
         x: $windows.-bt-sources-setup.exe
         x:-setup.exe
         x:windows-system32-cmd /k startnet.cmd

hi,
Not long ago, I tested the WinRe-based version produced by Wimbuilder2 of Slore.

The WinRe-based version displays the mouse pointer (mouse cursor) as soon as the small rotating points disappear.
This prevents an all-black screen from being displayed for tens of seconds.
On my WinPe-based version, this mouse pointer display is missing and the screen stays black for too long.
This lack of display suggests that WinPe is "bad or hangs up".
I looked for where this difference came from and found this:
https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/no-mouse-cursor-during-osd-task-sequence
HKEY_LOCAL_MACHINE-SOFTWARE-Microsoft-Windows-CurrentVersion-Policies-System
EnableCursorSuppression - 0 Mouse cursor is not suppressed

I also tried to replace the various commands "netcfg" to set up the network as does WinRe.
I didn't really understand the structure of the Network and NetworkSetup2 keys.
I will try to prepare them during the construction phase.

I also can't figure out how WinRe sets up the settings for the video
If anyone can give me any information, that would be nice.

Hi noelBlanc,

Sorry, too late. if I had known You were looking for visible mouse pointers at PE-startup (EnableCursorSuppression),
I would have loved to share the info with You, which can be found @ TheOven here:
Reply #16 on February 06, 2018, 07:56:03 PM by oxydw @ http://theoven.org/index.php?topic=2050.msg25838#msg25838

For a long time I have been following your efforts to get things going with great interest and respect. Thanks a lot for sharing.

In particular, I read your comments about Bluetooth very carefully, which helped me to integrate the M$ Bluetooth Subsystem into Win10PESE.
But at the moment the device pairing process doesn't work here.

I start the search process with "X:\Windows\System32\DevicePairingWizard.exe" on the command line
but it ends after a while without finding My bluetooth device that is nearby.
As is well known, this also works successfully in normal Windows in addition to the modern app options.
When I use NiSoft's bluetoothview.exe it shows My Bluetooth device but clicking on connect ends with error 10049.
So, I think it maybe has to do with the authorization of bluetooth devices or something. Do not know what is missing.

I also saw reply #226 by Slore in this topic but did not found info about the comment "I got bluetooth worked with WimBuilder2's 20 lines batch code."
in his packages WimBuilder2-Full.v202x-xx-xx.7z

May I ask you if You have come a little further with Your announcement from Your reply #223 in this topic regarding: "...  integrate bluetooth ..."?
Or You have an idea how to get pairing working?

I use latest Win10PE_SE_2020-03-28.zip with source Win10 1809 DE x32 iso on host Win10 1909 pro x64.

Regards

hi HeyJoe

First, thank you very much for your good words. I am very honored, sincerely, because I am not a guru, just a perpetual novice who occupies my retirement time

i can't read english texts and i misunderstand very often what i read in officlal documentation like ones come from MS and others. My knowlegde is limited. Sometimes i'm wrong but i don't know i'm wrong. And what is good in a winpe version is not necessary good in the next one.
I always try to explain how I found a feature or information (citing my sources, trace windbg...) because I'm sure the method is more important than the gross or raw result for some end users who can then adapt the method to their needs. And in this time of virus "ransonware and co...), my fear of using one program written by another takes on its full value. I use scripts (readable sources) or programs that don't work very well but that I write myself.

About Bluetooth, i just try in my 20h2 version:
- i can connect ( i use "my" exe to connect, device...wizard.exe : not ok !) to my headless device
- but i cant' see it in the "sound panel".
Something is wrong in my work with this 20h2 version  and :-((
I didn't test it in the new versions because i'm lazy.
I'll search and  write more later.
And i must begin with a test in "fulflat" ( a long time !)
Sorry.

Hi, Noel

The WinRe-based version displays the mouse pointer (mouse cursor) as soon as the small rotating points disappear.

call Winpeshl.exe will show the mouse cursor on booting, or change the registry item you found.

https://github.com/slorelee/wimbuilder2/blob/master/Projects/WIN10XPE/00-Configures/x-Account/Admin/SwitchToAdmin.bat

Code: [Select]

  rem Enable Mouse Cursor (EnableCursorSuppression=0) or use Exec = Winpeshl.exe in PecmdAdmin.ini
  reg add HKLM\Tmp_Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableCursorSuppression /t REG_DWORD /d 0 /f

This is in WIN10XPE's PecmdAdmin.ini for long time.

On my WinPe-based version, this mouse pointer display is missing and the screen stays black for too long.

I think yours had lots of devices need to load the 3rd part drivers.

Try to disable the Network feature on booting,
call winpeinit.exe, wpeutil.exe InitializeNetwork after the shell.
Maybe the black screen will be in shorter time.

You can check the winpeshl.log, wpeinit.log,  INF\setupapi.dev.log to see which phase takes the boot time.

I didn't really understand the structure of the Network and NetworkSetup2 keys.

I don't understand, too. but if you remove the ms_pacer filter, the network tray icon will show the right status directly.

https://github.com/slorelee/wimbuilder2/blob/master/Projects/WIN10XPE/01-Components/02-Network/_networklist.bat

Code: [Select]

    call RegCopy HKLM\System\ControlSet001\Control\NetworkSetup2\Filters
    rem remove ms_pacer filter(QoS Packet Scheduler)
    reg delete HKLM\Tmp_System\ControlSet001\Control\NetworkSetup2\Filters\{B5F4D659-7DAA-4565-8E41-BE220ED60542} /f

Winre.wim has the Narrator.exe(Read the screen information) by default, so the basic audio serive in RUNNING.
No sets up the settings for that.

For video, you'd better to add display card driver, some dll files of Direct3D.

Hi, HeyJoe

I also saw reply #226 by Slore in this thread but did not found info about the comment "I got bluetooth worked with WimBuilder2's 20 lines batch code."
in his packages WimBuilder2-Full.v202x-xx-xx.7z

It is not release to the public so far, I committed it on gitee.com (the Chinese source repo service).

https://gitee.com/slorelee/wimbuilder2/blob/master/Projects/WIN10XPE/01-Components/Bluetooth/main.bat

It will be included in the next WimBuilder2-Full.v2021-03-03.7z package. My can download the main.bat and add it manually,
or change the source URL to gitee, and execute next command in Advance page.

Code: [Select]

call _updater --file Projects/WIN10XPE/01-Components/Bluetooth/main.bat

(The Bluetooth feature shows in the Developer Mode of WimBuilder2)

I tested this file list, and drivers for my smart phone device, it still works with Windows 20h2 source.

Next options are required:
1. full SOFTWARE hive
2. Devices And Printers - Printers

In the WinPE, you have to wait 10 minutes for the Control Panel\Devices And Printers to init,
then you can see your bluetooth device and click the Add new Device button to use DevicePairingWizard.exe to pair the device.

I don't have other Bluetooth device, I just tested with my smart phone.