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

@ChrisR
From Session System : files are downloaded well but not display
I find them ( many try before i see in directory) in directory.
See picture...

I continue to play with IE11-64bits in the ADM session. I wanted to use the debugger F12. At first, it miss some files.
Now, i can get the network trace. it use the service "diagnosticshub.standardcollector.service".
I tryed also "fiddler". In my first test, fiddler ask to install its certificat for https. I install it with certutil.exe.
Not a revolution.

Hello,
Today, i play with windbg.exe. I look into the code of Shell_TrayHwd.
As said in some posts before, with SPY, and as it was said in old posts in theoven, the message 0x579 is send to the wndproc Shell_TrayHwd when you want swap to/from the desktop. With windbg, i find a byte in this wndproc which enable the displying of the desktop, and the reverse swap.
I put here some informations from IE in winpe ( yes, it woks enougth but i can't attach a file ).
I translate as soon as possible.

A -Configure the symbol servers and the network for windbg

B - We saw with spy ++ thewindow Shell_TrayHwd receives the message 0 x 579 with wParam = 3

C - identify the handle and address of WndProc to Shell_TrayHwd
   with spy ++ that gives the offset of this window and the handle
   with a bit of PS that gives the Hinstance which we keep the segment
   7ff7`B8714A40

D - so we can attach windbg to process explorer.exe (office administrator)

1 - We put a conditional breakpoint with:
   bp 7ff7`B8714A40 ".if (rcx == 0x2007E  &  rdx == 0x579 &  r8 == 3) {.echo msg ok} .else {gc;}"

E - we click below and to the right of the screen

F - activity of windbg greatly slows the process 'explore': wait

2 - code analysis activity: the wndproc begins with a big "switch" to process messages WM_xxxxxxxx

3 - symbols and step by step allow to navigate in the code
   Explorer!CImpWndProc::s_WndProc      : pour la wndproc
   Explorer!CTray::v_WndProc                    : for the treatments carried out by this wndproc, other messages are sent to "child" windows (I suppose)

4 - the switch is sometimes complex because optimized by the compiler certainly.
   Here the value of the message 0 x 579 is manipulated pure become an index into a table of pointers
   Explorer!CTray::v_WndProc+0x404:
   00007ff7`b8716964 8d83affaffff    lea     eax,[rbx-551h]
   00007ff7`b871696a 83f87d          cmp     eax,7Dh
   00007ff7`b871696d 779c            ja      Explorer!CTray::v_WndProc+0x3ab (00007ff7`b871690b) [br=0]
   00007ff7`b871696f 488d158a96fbff  lea     rdx,[Explorer!std::_Uninit_move<Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> * __ptr64,Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> * __ptr64,std::allocator<Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> >,Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> > <PERF> (Explorer+0x0) (00007ff7`b86d0000)]
   00007ff7`b8716976 0fb68402607b0400 movzx   eax,byte ptr [rdx+rax+47B60h] ds:00007ff7`b8717b88=0d
   00007ff7`b871697e 8b8c82a87a0400  mov     ecx,dword ptr [rdx+rax*4+47AA8h] ds:00007ff7`b8717adc=0004698a
   00007ff7`b8716985 4803ca          add     rcx,rdx
   00007ff7`b8716988 ffe1            jmp     rcx {Explorer!CTray::v_WndProc+0x42a (00007ff7`b871698a)}

5 - Continuing the step by step, we find a call whose name is evocative
   Explorer!CTray::v_WndProc+0x43d:
   00007ff7`b871699d e88af1ffff      call    Explorer!CTray::_RaiseDesktop (00007ff7`b8715b2c)

6 -Continuing, we find a test that sends in a case of mistaken (my assumption at the time because of there also evocative text)
   Explorer!CTray::_RaiseDesktop+0x29:
   00007ff7`b8715b55 3899f9020000    cmp     byte ptr [rcx+2F9h],bl ds:00007ff7`b88f5b19=01  <<<<<<<<<<<<<<< the byte !!!
   00007ff7`b8715b5b 0f85ab5a0700    jne     Explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor    for 'wrapper''+0x13dcc (00007ff7`b878b60c) [br=1]

G - I leave windbg and the stimulus to place a single breakpoint on this cmp instruction in order to change the value of this byte
   bp 00007ff7`b8715b55 ".if (r8 == 0x579 &  r9 == 3) {.echo msg ok} .else {gc;}"

H - I click at the bottom right of the screen

I - i change the byte

J - toggles the display takes place! It persists as long as I am not leaving the administrator session.

Conclusion: this isn't a huge step forward. But this has occupied my day.

hello,
It was very long, but i get it : with a hook DLL, i can reset the byte "base +2F9".

And now, the touch "Windows + D" is enabled/active.

Yes, winPeSe got it since a long time with the use of  "wind.exe and MsgHook.dll".
And Yes, this solution is not a good idea because with the next version of winpe, the address will be modify.

But now, with windbg, it become perhaps possible to find why and when this byte is set to 1.

For my memory, the base is given by SPY++ in the "windows Bytes".

I put the tow codes here. I compile them with VSCommunity 2013 in 64bits only. Create a project and add these codes seems simple.
And yes, my code is horrible, i'm not a good developper.

For install : in a cmd,  launch the program, it puts a hook in Shell_TrayWnd and wait, so explorer launch the dll, the dll modify the byte, you can press a touch in the cmd , so the program remove the hook. If explorer is killed ( tscon 1 for sample) the byte decomes set to 1. And it need to do again.
Sorry for my english. I hope someone can understand...

Great work Noel 

For x86 it's *CTrayObj + 0x231

@JFX   I am very touched by your words of encouragement.

It's true that I leave completely to one side the 32-bit version. I'm not quite good to manage multiple environments.
Currently, I'm trying to follow the creation of this byte with windbg. The breakpoint "ba r 1 adr" when loading to explore does not fire when setting to 1. Here, I do not understand.
Perhaps not the good method....

PS : Do you think it will be possible to find "automaticaly" the address of this byte for the next versions ?

Hmm, will be difficult to find it for other version.
Would be easier if we could find the reason why this byte is set in WinPE.

hello,
Not easy to follow the life of this byte. The "ba r 1 adr" breakpoint does not work when this bit is set to 1. But he triggered when readings. The doc makes it clear that the option "r" means "read and write". I tried to "go back" since the RegisterClass call. But this byte is already positioned before the first call.

0:000 &gt; db 7FF7 '93FC5B19--->>> 00007ff7' 93fc5b19 00
BP USER32! RegisterClassExW
g
ModLoad: 00007ff8 '18840000 00007ff8' 1886e000 X:\windows\System32\IMM32. DLL
ModLoad: 00007ff8 '18f60000 00007ff8' 190bb000 X:\windows\System32\MSCTF.dll
Breakpoint 0 hit
0:000 &gt; db 7FF7 '93FC5B19--->>> 00007ff7' 93fc5b19 01

Seeking a little more (even a long time), I find a loop (n = 0 x 19): call msvcrt! _guard_dispach_icall_fptr. It is located in msvcrt! initterm + 0x3d. Byte changes value between 0xB and 0x16 iterations. I missed a good time.
As it is certainly the initialization of global data, I guess that the default value is 1. And so this byte must certainly change its value by an external action (message or subsequent test).
It seems more sensible to put a breakpoint "ba" on this byte in loading a explore in w10. But I must say that I am a little tired today.

Today it's raining.
I just follow changes to the byte 2F9 in "explorer.exe" in Windows 10 build 14393.rs1_release_inmarket.170303 - 1614. But I think that would be the same in all versions of this build 14393.
The attached file contains the trace of the windbg and my comments in french.
I translate the most important here.
Getting started: check the address and the 'windows bytes' with spy ++ to the window "Shell_TrayWnd".
Start windbg. Kill Explorer.exe. In windbg, open the program "explorer.exe".
compute the address of the byte: the basis is provided by spy ++ in the 'windows bytes'. Add 2F9 for build 14393.
Note: I don't remember if I explained how to find this address.
Place the breakpoint:
ba w 1 00007ff6'01e76b59
and GO (g in the file)
explore starts and loads more other dll.
If the address is correct then the breakpoint is triggered.
Breakpoint 0 hit
explore! CTray:v_WndProc + 0xfa6:
00007ff6'01c96a86 84c0 test al, al                                     it is the previous instruction which is important!

Now, how to get le code before this instruction ?
Because it's really the previous code that will tell who and how this byte is changed. Try to deassemble going up in addresses, we quickly found that it is not possible to identify the address of the "jmp" that brought on this "move in 00007ff6'01c96a7f" in my case.
Therefore start from the entrance of the WndProc of a window.

But by looking at the values of the registers and in constant statements following the code launch a "PostMessage", I think that the treatment should not be very long and that may be what would be a response to another message and why "0X5BA" contained in the registers "rbx" and r8.

so we go to the WndProc with:
u explore! CTray::v_WndProc
see the code in the file if you need...

I guess that the msg = 5BA like i see in rbx and r8 at the time of the "BA" breakpoint
I need to get the good address :
00007ff6`01c95ef6 0fb68402e0700400 movzx   eax,byte ptr [rdx+rax+470E0h]
00007ff6`01c95efe 8b8c8228700400  mov     ecx,dword ptr [rdx+rax*4+47028h]
00007ff6`01c95f05 4803ca          add     rcx,rdx
00007ff6`01c95f08 ffe1            jmp     rcx
So :
rax = 0x5BA -0x551  = 0x69
rdx = 00007ff6'01c50000? the charging base of the prg according to the logic of loading to a prg in PE format
byte * ptr = [rdx + rax + 470E0h] = 00007ff6'01c50000 + 0x69 + 0x470E0 = 00007ff6'01c97149 = 0x1B
0:010 d 00007ff6'01c97149
00007ff6'01c97149 1b 1c 2d 1d 1e 1f 2d 20-21 22 23 24 25 26 27 2d... -...- !" #$%&'-
DWORD * ecx = [rdx + rax * 4 + 47028 h] = 00007ff6'01c50000 + (0x1B * 4) + 0 x 47028 = 00007ff6'01c97094
0:010 d 00007ff6'01c97094
00007ff6'01c97094 74 6a 04 00 e0 65 04 00-45 6a 04 00 63 04 00 tj b9 e... EJ... c...
                  74 6a 04 00 in memory = 0004674 in address
rcx = 00007ff6'01c50000 + 0x00046A74 = 00007ff6'01c96a74

And jmp     rcx !
And there's the code in 00007ff6'01c96a86 at the breakpoint

0:010> u 00007ff6`01c96a74
explorer!CTray::v_WndProc+0xf94:
00007ff6`01c96a74 397d88          cmp     dword ptr [rbp-78h],edi
00007ff6`01c96a77 0f8526660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x15123 (00007ff6`01d0d0a3)
00007ff6`01c96a7d 8bc7            mov     eax,edi
00007ff6`01c96a7f 418887f9020000  mov     byte ptr [r15+2F9h],al >>>>>>>>>>>>>>>>> on retrouve bien l'adresse du ba
00007ff6`01c96a86 84c0            test    al,al
00007ff6`01c96a88 0f851f660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
00007ff6`01c96a8e 4138bff8020000  cmp     byte ptr [r15+2F8h],dil
00007ff6`01c96a95 0f8512660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
0:010> u
explorer!CTray::v_WndProc+0xfbb:
00007ff6`01c96a9b 440fb6c0        movzx   r8d,al
00007ff6`01c96a9f 4533c9          xor     r9d,r9d
00007ff6`01c96aa2 ba0c040000      mov     edx,40Ch
00007ff6`01c96aa7 498b8fa0000000  mov     rcx,qword ptr [r15+0A0h]     DESTINATAIRE INCONNU unknow dest but but but .....
00007ff6`01c96aae ff15c4431800    call    qword ptr [explorer!_imp_SendMessageW (00007ff6`01e1ae78)]
00007ff6`01c96ab4 e918f3ffff      jmp     explorer!CTray::v_WndProc+0x2f1 (00007ff6`01c95dd1)

Summarizes:
someone sends the message 0x5BA with Wparam = 0 and lParam = 0 at the window "Shell_TrayWnd"

The final test: winpe into this piece of PS

Code: [Select]

$code=@'
using System;
using System.Runtime.InteropServices; 
namespace Win32_API
{
public class Win32_API_Class
{
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindowEx(IntPtr parentHandle, IntPtr childAfter, string className,  string windowTitle);
[DllImport("user32.dll")]
public static extern int SendMessage(int hWnd, int hMsg, int wParam, int lParam);
}
}
'@
add-type -TypeDefinition $code

$handle = [Win32_API.Win32_API_Class]::FindWindow("Shell_TrayWnd", "");
$iRet   = [Win32_API.Win32_API_Class]::SendMessage($handle, 0x5BA, 0, 0);

Et Bingo !

It would be interesting to know who is the sender of this message 5BA.
Is it a method without  windbg?

You rock man 

Seems it's explorer himself who send this message.

@JFX: thanks for the encouragement

I think I recognise a listing generated by IDA. Isn't it ?

Yes it's IDA 6.8 with loaded x64 explorer.exe version 14393.

I guess the CTray object has it's own function to enable\disable the show desktop functionallity.

is IDA 64bits 6.8  free of charge ?

With windbg i can see explorer!CTray::ModeChanged.
I don't know if i can find some thing if i put a BP.
Perhaps with the crossref....

Merci.

hello,
i open explorer.exe in windbg on my windows10 "normal"
i  put a breakpoint on explorer!CTray::ModeChanged.
And "go" with "g" : No hit !
I try twice.
I don't understand why. Is it possible that there are an other code in explorer that send the 5BA message ?

hello,
I put a "ba w 1 add_2F9" in a explorer on windows10 "normal".
I can't see the transmitter's handle. But i can see the destinataire's handle of the msg 0X40C (send when the byte is reset).
It's "TrayNotifyWnd".
If i suppose transmitter is also the destinataire. Do you think so ?
In this case, can we imagine a handshaking ( i hope it's the good word ) between these 2 windows?
- shell_TrayWnd sets by default the flag 2F9 : witch means that TrayNotifyWnd is not create
- TrayNotifyWnd sends the msg 5BA : that means that TrayNotifyWnd is ok
- shell_TrayWnd  resets the byte and now can operate the events ( keyboard, menu, msg ) about  "display desktop"
If so, why is it different in winpe?
A long way to explore TrayNotifyWnd ....
Sun is shining so i go to cycle

PS : during the manipulation, in windbg, I used the "p" command to execute the call to postMessage 40 c. Then I let the program continue with "g". And now wanting to shut down the pc, I see that the 'windows' key and click 'mouse' on the window at the bottom left are inactive as in Winpe. Something to follow can be...

Hi Noel,

Good weather here, so I'm not going into the headache of why WinPE not sends this message.
I've updated my WinPE loader to fire this message on every time it receives a wm_taskbarcreated message.
This seems to be a perfect solution.

Hi JFX,
Good thing !
I must say that i don't know the wm_taskbarcreated message before you speak about it.
Thanks for sharing the information

hello,
But who sent this message 0x5BA in the case of a "normal" windows10?
Quickly...

We therefore have a breakpoint in Windows 10 "normal" on the address of the function PostMessage:

BA r 8 explore! _imp_PostMessageW ".if(rdx == 0x5BA) {.echo msg 5BA} .else {gc};"

There are several exceptions that activate Windbg. I do not account. And finally, the breakpoint is triggered with the 0x5BA message.

USER32!PostMessageW:
00007ff9`610dafa0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000000`0326ef88=00007ff6a3496890
:010> r
rax=0000000000000000 rbx=00007ff6a3496860 rcx=000000000005021e
rdx=00000000000005ba rsi=0000000000000004 rdi=0000000000000000
rip=00007ff9610dafa0 rsp=000000000326ef78 rbp=000000000326efd0
 r8=0000000000000000  r9=0000000000000000 r10=00000fff28e681da
r11=0000000004010000 r12=00007ff6a3429040 r13=000000000005021e
r14=0000000000000000 r15=0000000000000003
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
USER32!PostMessageW:
00007ff9`610dafa0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000000`0326ef88=00007ff6a3496890
0:010> k
 # Child-SP          RetAddr           Call Site
00 00000000`0326ef78 00007ff6`a32ba651 USER32!PostMessageW
01 00000000`0326ef80 00007ff6`a32b76d0 explorer!CTray::_RegisterForNotifications+0xf5
02 00000000`0326f000 00007ff6`a32f2b27 explorer!CTray::StartTaskbar+0xf4
03 00000000`0326f050 00007ff6`a32b7880 explorer!CTray::_StartTaskbarApiSurface+0x37
04 00000000`0326f080 00007ff6`a32b7a79 explorer!CTray::_StartParallelTasks+0xd8
05 00000000`0326f0c0 00007ff6`a32b6425 explorer!CTray::_HandleStartupProgress+0x155
06 00000000`0326f100 00007ff6`a32b4112 explorer!CTray::v_WndProc+0x945
07 00000000`0326f630 00007ff9`610d1c24 explorer!CImpWndProc::s_WndProc+0xe2
08 00000000`0326f680 00007ff9`610d156c USER32!UserCallWinProcCheckWow+0x274
09 00000000`0326f7e0 00007ff6`a32bac69 USER32!DispatchMessageWorker+0x1ac
0a 00000000`0326f860 00007ff6`a32f7ae3 explorer!CTray::_MessageLoop+0x149
0b 00000000`0326f8f0 00007ff9`5eef5aad explorer!CTray::MainThreadProc+0x43
0c 00000000`0326f920 00007ff9`60e88364 SHCORE!Microsoft::WRL::Details::RuntimeClass<Microsoft::WRL::Details::InterfaceList<CRandomAccessStreamBase,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IRandomAccessStreamWithContentType,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IContentTypeProvider,Microsoft::WRL::Details::InterfaceList<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<3>,Microsoft::WRL::CloakedIid<IRandomAccessStreamMode>,Microsoft::WRL::CloakedIid<IRandomAccessStreamFileAccessMode>,Microsoft::WRL::CloakedIid<IObjectWithDeferredInvoke>,Microsoft::WRL::CloakedIid<IObjectWithFileHandle>,Microsoft::WRL::CloakedIid<IUnbufferedFileHandleProvider>,Microsoft::WRL::CloakedIid<IRandomAccessStreamPrivate>,Microsoft::WRL::CloakedIid<ITransactedModeOverride>,Microsoft::WRL::CloakedIid<CFTMCrossProcServer>,Microsoft::WRL::Details::Nil>,Microsoft::WRL::Details::Nil> > > >,Microsoft::WRL::RuntimeClassFlags<3>,1,1,0>::~RuntimeClass<Microsoft::WRL::Details::InterfaceList<CRandomAccessStreamBase,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IRandomAccessStreamWithContentType,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IContentTypeProvider,Microsoft::WRL::Details::InterfaceList<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<3>,Microsoft::WRL::CloakedIid<IRandomAccessStreamMode>,Microsoft::WRL::CloakedIid<IRandomAccessStreamFileAccessMode>,Microsoft::WRL::CloakedIid<IObjectWithDeferredInvoke>,Microsoft::WRL::CloakedIid<IObjectWithFileHandle>,Microsoft::WRL::CloakedIid<IUnbufferedFileHandleProvider>,Microsoft::WRL::CloakedIid<IRandomAccessStreamPrivate>,Microsoft::WRL::CloakedIid<ITransactedModeOverride>,Microsoft::WRL::CloakedIid<CFTMCrossProcServer>,Microsoft::WRL::Details::Nil>,Microsoft::WRL::Details::Nil> > > >,Microsoft::WRL::RuntimeClassFlags<3>,1,1,0>+0x135
0d 00000000`0326fa10 00007ff9`61a470d1 KERNEL32!BaseThreadInitThunk+0x14
0e 00000000`0326fa40 00000000`00000000 ntdll!RtlUserThreadStart+0x21

The PostMessage call came from the "explore! CTray::_RegisterForNotifications".

explorer!CTray::_RegisterForNotifications+0xc6:
00007ff6`a32ba622 488b4df0        mov     rcx,qword ptr [rbp-10h]
00007ff6`a32ba626 488b01          mov     rax,qword ptr [rcx]
00007ff6`a32ba629 488d5538        lea     rdx,[rbp+38h]
00007ff6`a32ba62d 488b4018        mov     rax,qword ptr [rax+18h]
00007ff6`a32ba631 ff15b1191800    call    qword ptr [explorer!_guard_dispatch_icall_fptr (00007ff6`a343bfe8)]
00007ff6`a32ba637 85c0            test    eax,eax
00007ff6`a32ba639 7817            js      explorer!CTray::_RegisterForNotifications+0xf6 (00007ff6`a32ba652)
00007ff6`a32ba63b 4c634538        movsxd  r8,dword ptr [rbp+38h]
0:010> u
explorer!CTray::_RegisterForNotifications+0xe3:
00007ff6`a32ba63f 4533c9          xor     r9d,r9d
00007ff6`a32ba642 baba050000      mov     edx,5BAh >>>>>>>>>>>>>>>>>>>>> breakpoint
00007ff6`a32ba647 488b4b08        mov     rcx,qword ptr [rbx+8]
00007ff6`a32ba64b ff158f071800    call    qword ptr [explorer!_imp_PostMessageW (00007ff6`a343ade0)]
00007ff6`a32ba651 90              nop
00007ff6`a32ba652 488d4df0        lea     rcx,[rbp-10h]
00007ff6`a32ba656 e80534fcff      call    explorer!Microsoft::WRL::ComPtr<Windows::Foundation::IAsyncOperation<Windows::Foundation::Collections::IVectorView<Windows::ApplicationModel::StartupTask * __ptr64> * __ptr64> >::InternalRelease (00007ff6`a327da60)
00007ff6`a32ba65b 4c897540        mov     qword ptr [rbp+40h],r14

Found the code to send the 0x5BA message
The call to explore! CTray::_EnsureImmersiveShellPointer in Winpe will certainly pose a concern.

explorer!CTray::_RegisterForNotifications+0x29:
00007ff6`083eb005 e8dea6ffff      call    explorer!CTray::_EnsureImmersiveShellPointer (00007ff6`083e56e8)
0:010> p
explorer!CTray::_RegisterForNotifications+0x2e:
00007ff6`083eb00a 85c0            test    eax,eax
0:010> r
rax=0000000080040154 rbx=00007ff6085c5820 rcx=0000000000000000
rdx=0000000080040154 rsi=0000000000000004 rdi=0000000000000000
rip=00007ff6083eb00a rsp=000000000361eeb0 rbp=000000000361ef00
 r8=000000000361e9c8  r9=00000000000021f5 r10=0000000000000000
r11=000000000361ec30 r12=00007ff608550d20 r13=0000000000030114
r14=0000000000000000 r15=0000000000000003
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
explorer!CTray::_RegisterForNotifications+0x2e:
00007ff6`083eb00a 85c0            test    eax,eax
00007ff6`083eb00c 0f8860010000    js      explorer!CTray::_RegisterForNotifications+0x196 (00007ff6`083eb172) [br=1]

Code return rax = 0000000080040154 = class not registered.
The jump prohibits sending the msg 5BA.
The function "explore! CTray::_EnsureImmersiveShellPointer"use DCOM.

0:010> u explorer!CTray::_EnsureImmersiveShellPointer
explorer!CTray::_EnsureImmersiveShellPointer:
00007ff6`083e56e8 4883ec38        sub     rsp,38h
00007ff6`083e56ec 4881c158030000  add     rcx,358h
00007ff6`083e56f3 33c0            xor     eax,eax
00007ff6`083e56f5 483901          cmp     qword ptr [rcx],rax
00007ff6`083e56f8 0f84fc5c0700    je      explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x13bba (00007ff6`0845b3fa)
00007ff6`083e56fe 4883c438        add     rsp,38h
00007ff6`083e5702 c3              ret
00007ff6`083e5703 cc              int     3
explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x13bba:
00007ff6`0845b3fa 48894c2420      mov     qword ptr [rsp+20h],rcx
00007ff6`0845b3ff 4c8d0d92381100  lea     r9,[explorer!GUID_6d5140c1_7436_11ce_8034_00aa006009fa (00007ff6`0856ec98)]
00007ff6`0845b406 488d0d139c1100  lea     rcx,[explorer!GUID_c2f03a33_21f5_47fa_b4bb_156362a2f239 (00007ff6`08575020)]
00007ff6`0845b40d 33d2            xor     edx,edx
00007ff6`0845b40f 41b804040000    mov     r8d,404h
00007ff6`0845b415 ff159dee1000    call    qword ptr [explorer!_imp_CoCreateInstance (00007ff6`0856a2b8)]
00007ff6`0845b41b 90              nop
00007ff6`0845b41c e9dda2f8ff      jmp     explorer!CTray::_EnsureImmersiveShellPointer+0x16 (00007ff6`083e56fe)

rcx = explorer!GUID_c2f03a33_21f5_47fa_b4bb_156362a2f239 -->> HKCR/c2f03a33_21f5_47fa_b4bb_156362a2f239/default=Immersive Shell, APPID={316cded5-e4ae-4b15-9113-7055d84dcc97} ( appid/runas=Interactive User )
rdx = NULL
r8  = 404h -->>> CLSCTX_LOCAL_SERVER = 0x4   CLSCTX_NO_CODE_DOWNLOAD = 0x400,
r9  = explorer!GUID_6d5140c1_7436_11ce_8034_00aa006009fa --------------->>>>>>>>>>>>> ?????????????

[HKEY_CLASSES_ROOT\CLSID\{c2f03a33-21f5-47fa-b4bb-156362a2f239}]
@="Immersive Shell"
"AppID"="{316cded5-e4ae-4b15-9113-7055d84dcc97}"
[HKEY_CLASSES_ROOT\AppID\{316CDED5-E4AE-4B15-9113-7055D84DCC97}]
@="Immersive Shell"
"RunAs"="Interactive User"
[HKEY_CLASSES_ROOT\Interface\{6D5140C1-7436-11CE-8034-00AA006009FA}]
@="IServiceProvider"
[HKEY_CLASSES_ROOT\Interface\{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32]
@="{A6FF50C0-56C0-71CA-5732-BED303A59628}"
[HKEY_CLASSES_ROOT\CLSID\{A6FF50C0-56C0-71CA-5732-BED303A59628}]
@="PSFactoryBuffer"
[HKEY_CLASSES_ROOT\CLSID\{A6FF50C0-56C0-71CA-5732-BED303A59628}\InProcServer32]
@="C:\\Windows\\System32\\OneCoreCommonProxyStub.dll" ------------------------------>>>>>>>>>>>>> ?????????????
"ThreadingModel"="Both"

How to go further?

Actually i work to get mstsc with RemoteDesktop Gateway server.
And i find that my scripts traitement.ps1  can't work with language en-us.
I 'll fix soon.
Constat : scripts not usefull because no one send me that scripts doesn't work.

Hi,noelBlanc

nice to see the problem(ShowDesktop) has perfect solution!

Yes, winPeSe got it since a long time with the use of  "wind.exe and MsgHook.dll".
And Yes, this solution is not a good idea because with the next version of winpe, the address will be modify.

You wrong, wind.exe will deal with all version.

I'm not good as your in disassembling program, I just debug explorer.exe with
Visual Studio, find the message.
I hook the massage, and MinimizeAll/UnMinimizeAll the Windows with my code.
(compare to make origin explorer function work, this is easy for me, just write 100 lines code in 1 or 2 hours.)

but follow your description I try and got the same thing in 10.0.15063. 
(code has a bit different.)

I want make a hard patch to switch the default jump, but the explorer.exe cann't startup with the change...

Code: [Select]

00007ff6`01c96a7f 418887f9020000  mov     byte ptr [r15+2F9h],al >>>>>>>>>>>>>>>>> on retrouve bien l'adresse du ba
00007ff6`01c96a86 84c0            test    al,al
00007ff6`01c96a88 0f851f660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
00007ff6`01c96a8e 4138bff8020000  cmp     byte ptr [r15+2F8h],dil
00007ff6`01c96a95 0f8512660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`   >>>>>>>>> change jne to je