WinRE SMB networking broken?

[dabl]

I'm running Windows 11 Pro 25H2 OS build 26200.8894 with WinRE 10.0.26100.8875

When I boot into WinRE, ipconfig shows my NIC. So far so good.

After running winpeinit, ipconfig shows my network and I can ping machines on it. So far so good.

After attempting to unsuccessfully map a drive or even dir via ip a known machine address and share, looking futher I realized per below that Lanman Workstation isn't running and can't be started because one of the the dependencies, MRxSmb20 can't be started.

Grabbing a current media creation tool I make a bootable usb installer to use for testing a clean WinRE environment. At the time of this writing this builds Microsoft Windows 10.0.26100.1, WinRE 10.0.26100.8873

I get the same results.

Possibly it's related to my NIC?

I've tried with my Lenovo ThinkPad Universal Thunderbolt 4 Dock 40B00135U and a Lenovo USB-C to 2.5G Ethernet Adapter, both are idenitifed as a Realtek USB GbE Family Controller. Also tried with a Surface Pro 11 ARM machine and dock with a network card ID'ing as Realtek.

Just wondering if I'm the Lone Ranger and if anybody else might be able to confirm they are able to run WinRE (any version) with SMB networking functioning.

Windows 11 Pro 25H2 OS build 26200.8894, WinRE 10.0.26100.8875

C:\Windows\System32>sc query lanmanworkstation

SERVICE_NAME: lanmanworkstation
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1068 (0x42c)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Windows\System32>sc qc lanmanworkstation
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: lanmanworkstation
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : X:\windows\System32\svchost.exe -k NetworkService -p
LOAD_ORDER_GROUP : NetworkProvider
TAG : 0
DISPLAY_NAME : Workstation
DEPENDENCIES : MRxSmb20
: NSI
: Bowser
SERVICE_START_NAME : NT AUTHORITY\NetworkService

C:\Windows\System32>sc query nsi

SERVICE_NAME: nsi
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Windows\System32>sc query bowser

SERVICE_NAME: bowser
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Windows\System32>sc query mrxsmb20

SERVICE_NAME: mrxsmb20
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 127 (0x7f)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Windows\System32>sc qc mrxsmb20
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: mrxsmb20
TYPE : 2 FILE_SYSTEM_DRIVER
START_TYPE : 3 DEMAND_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : system32\DRIVERS\mrxsmb20.sys
LOAD_ORDER_GROUP : Network
TAG : 7
DISPLAY_NAME : SMB 2.0 MiniRedirector
DEPENDENCIES : mrxsmb
SERVICE_START_NAME :

C:\Windows\System32>sc query mrxsmb

SERVICE_NAME: mrxsmb
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Windows\System32>sc start mrxsmb20
[SC] StartService FAILED 127:

The specified procedure could not be found.

Windows Install USB, WinRE

C:\Windows\System32>ver

Microsoft Windows [Version 10.0.26100.1]

C:\Windows\System32>sc query lanmanworkstation

SERVICE_NAME: lanmanworkstation
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1068 (0x42c)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Windows\System32>sc qc lanmanworkstation
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: lanmanworkstation
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : X:\windows\System32\svchost.exe -k NetworkService -p
LOAD_ORDER_GROUP : NetworkProvider
TAG : 0
DISPLAY_NAME : Workstation
DEPENDENCIES : MRxSmb20
: NSI
: Bowser
SERVICE_START_NAME : NT AUTHORITY\NetworkService

C:\Windows\System32>sc query mrxsmb20

SERVICE_NAME: mrxsmb20
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 127 (0x7f)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Windows\System32>sc qc mrxsmb20
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: mrxsmb20
TYPE : 2 FILE_SYSTEM_DRIVER
START_TYPE : 3 DEMAND_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : system32\DRIVERS\mrxsmb20.sys
LOAD_ORDER_GROUP : Network
TAG : 7
DISPLAY_NAME : SMB 2.0 MiniRedirector
DEPENDENCIES : mrxsmb
SERVICE_START_NAME :

C:\Windows\System32>sc query mrxsmb

SERVICE_NAME: mrxsmb
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Windows\System32>sc start lanmanworkstation
[SC] StartService FAILED 1068:

The dependency service or group failed to start.

C:\Windows\System32>sc start mrxsmb20
[SC] StartService FAILED 127:

The specified procedure could not be found.

 

[ChatGPT]

Assessment​

dabl, this strongly looks like a WinPE/WinRE 26100 component regression, not a Realtek/NIC problem.

• IP, DHCP, and ICMP work.
• The failure occurs while Windows loads the local mrxsmb20.sys driver, before contacting the SMB server.
• Error 127 strongly suggests an unresolved kernel-driver export or mismatched SMB redirector components.
• You reproduced it across x64, ARM64, several adapters, installed WinRE, and Microsoft installation media.

Microsoft still documents net use \\server\share as supported in WinPE, so this is not an intentional removal of SMB2/3. Microsoft’s release-health pages do not currently list this as a known issue.

Useful confirmation test​

1. Copy these files from each failing environment to USB:

md D:\smbdiag
copy X:\Windows\System32\drivers\mrxsmb*.sys D:\smbdiag\
copy X:\Windows\System32\drivers\rdbss.sys D:\smbdiag\
copy X:\Windows\System32\drivers\mup.sys D:\smbdiag\
copy X:\Windows\System32\ntoskrnl.exe D:\smbdiag\

1. In normal Windows, inspect their versions:

Get-ChildItem D:\smbdiag | Select-Object Name,
@{n='Version';e={$_.VersionInfo.FileVersion}},
Length

1. Test an untouched 22621-based WinPE. If SMB works there but fails in 26100, that effectively confirms the regression.

Workaround​

Use a 22621-based custom WinPE temporarily, or build a 26100 WinPE image serviced with the complete matching cumulative update.
Do not manually transplant individual SMB drivers from the installed OS; mrxsmb20, mrxsmb, rdbss, mup, and the kernel are version-coupled.
I have not found an independent public confirmation yet, but your reproduction is already strong enough to report through Feedback Hub with sc start mrxsmb20 returning error 127.

 

[dabl]

Great, I suspected the same.

How can every machine I own running Windows 11 be failing this test in WinRE. Funny how it took a robot to confirm it and nobody else seemed to notice or care?

To be fair it's only been 5 days since the WinRE refresh to this version and perhaps not many people implement SMB networking on out of the box Windows 11 WinRE.

This forum definitely gets my thumbs up for implementing AI, hugely helpful. I used both ChatGPT (Plus) and Gemini but didn't feed them this actual full post. I should have.

This all started stemming from seeing this in Macrium Reflect X WinRE on a Microsoft Surface Pro 11 ARM machine. So WinPE is not an option there, at least as Macrium defines it for their rescue environment.

I've got an inquiry in with their tech support who are a little slow on the uptake so far. I gave them all the logs including the winpeinit.log from WinRE which clearly shows an error attempting to start LanmanWorkstation but they're still insisting I try mapping a drive using an ip address. Hello? logon/authentication can't happen if LanmanWorkstation isn't running. They asked me to run 'net start' following winpeinit in WinRE but didn't ask for the results. I gave it to them anyway pointing out 'Workstation' wasn't in the output.

I'll also post in the Macrium forums where there should hopefully be at least one other poor bastard trying to use the current WinRE in their Macrium Reflect X rescue environment. I know most Reflect X users just give up and use WinPE though. I certainly did on my non-ARM machines.

It will be interesting to see if any of the other ARM capable backup software (Hasleo etc) survived this regression if it turns out to actually be one.

 

[ChatGPT]

Thanks, dabl. One precision point: I haven’t personally boot-tested that WinRE build; your repeatable tests across x64, ARM64, several adapters, and clean Microsoft media provide the strong evidence. I’m confirming the technical diagnosis from those results.

Why every machine fails​

They are all using essentially the same Microsoft SafeOS/WinRE component set. Macrium’s WinRE rescue builder adds its application and drivers, but it still inherits Microsoft’s SMB redirector stack:
MUP → MRxSmb → MRxSmb20 → TCP/IP
Changing the Ethernet adapter only changes the lower networking layers. Since DHCP, ping, and IP connectivity work, the NIC driver has already done its job. The failure occurs higher up when mrxsmb20.sys attempts to load.
That also explains why x64 and ARM64 can exhibit the same problem: the binaries differ by architecture, but they can contain the same source-level or servicing regression.

Mapping by IP proves nothing different​

You are correct about Macrium’s suggestion. Using:
net use Z: \\192.168.1.10\Share
only bypasses DNS/NetBIOS name resolution. It does not bypass Workstation or MRxSmb20.
With:

MRxSmb20: error 127
LanmanWorkstation: error 1068

the request cannot reach SMB negotiation, authentication, or share permissions. Credentials are irrelevant until the local redirector can load.

Useful escalation evidence​

A particularly convincing reproduction would be:

1. Start a packet capture on the SMB server, filtered for TCP port 445.
2. In Macrium rescue, run:

wpeinit
sc start mrxsmb20
sc start lanmanworkstation
net use Z: \\<server-IP>\<share> /user:<username> *

1. Record the expected local failures:

MRxSmb20: error 127
LanmanWorkstation: error 1068

1. Show that no SMB negotiation reaches the server—and potentially no TCP 445 connection attempt at all.

The escalation wording should be:

Please reproduce using the current ARM64 Windows 11 WinRE. This is a local inbox SMB mini-redirector load failure occurring before name resolution, credentials, authentication, or server communication. Please escalate it to rescue-media engineering and Microsoft rather than continuing share-mapping diagnostics.

Other ARM backup products​

They will probably be affected if they build their rescue environment from the same current Microsoft WinRE image. They may survive if they:

• Ship a different WinRE component baseline.
• Use Linux recovery media.
• Implement their own network transport rather than Windows SMB.
• Access only local disks or USB storage.
• Have patched or replaced the affected component set.

I cannot say whether Hasleo is affected without testing its exact ARM64 rescue image. But if it uses the machine’s current WinRE unchanged, sc start mrxsmb20 would be the quickest litmus test.
For the Surface Pro 11, an older or corrected ARM64 WinRE base—or a local USB destination—is likely the only practical workaround until Microsoft or Macrium supplies an updated rescue environment. Do not transplant individual SMB .sys files between builds, because kernel and filesystem redirector components must remain version-matched.

 

[dabl]

This can also be reproduced by creating an.iso in Reflect X 10.0.8843 and choosing Win RE as the base WIM, then booting that in Windows Hyper-V.

WinRE 10.0.26100.8873 and 8875 at least appear to have broken SMB network functionality unless I'm missing something.

 

[ChatGPT]

Yes—booting the Reflect-generated ISO in Hyper-V is an excellent control test. It removes the physical NIC, USB adapter, dock, and machine firmware from the equation. The failure remains inside the 26100-based WinRE image and its SMB redirector stack.
Microsoft still documents mapping a share with:
net use N: \\server\share
as supported WinPE functionality, so this does not appear to be an intentional limitation.
The evidence now shows:

• wpeinit successfully initializes TCP/IP.
• Hyper-V’s synthetic NIC works, including ping.
• mrxsmb20.sys fails locally with error 127.
• LanmanWorkstation consequently fails with error 1068.
• The same behavior occurs with Microsoft and Reflect-generated WinRE media.
• It reproduces on physical systems and a virtual machine.

One qualification: I would describe it as affecting the current serviced WinRE 10.0.26100 images tested, rather than every historical 26100 revision. The ver command can report the base build while individual SafeOS components have newer servicing revisions.
For any Microsoft or Macrium report, your Hyper-V ISO reproduction is probably the cleanest case:

1. Create the ISO in Reflect X 10.0.8843 using WinRE.
2. Boot it in a Generation 2 Hyper-V VM.
3. Run wpeinit.
4. Confirm DHCP and ping.
5. Run:

sc start mrxsmb20
sc start lanmanworkstation
net use Z: \\<IP-address>\<share>

1. Record error 127, followed by 1068.

At this point, I do not think you are missing an ordinary configuration step. This looks like a reproducible WinRE component or servicing regression, and Macrium should escalate it rather than continue troubleshooting credentials or name resolution.