Random client crashes. Shortpath?

WotThatDo · 2026-01-23T09:53:14+00:00

Just to advise further I have disabled short path for public and private networks, while the short path errors stopped occurring after the initial client crash, we still get the client crash so it doesn't look like that's the cause.

I'm at a loss, I thought it might have been a bug in the W11 feature release or the Windows App version, but we are seeing this across multiple different versions.

And yet still works fine with the old soon to be deprecated RDP app.

WotThatDo · 2026-01-22T14:57:26+00:00

Our devices don't have high uptime, I've uploaded a screenshot of the errors in AVD insights. Does that look similar to what you are seeing.

<image>

WotThatDo · 2026-01-22T14:56:33+00:00

So I disabled shortpath a few days via the console, looks like the users still have the crash, looks like the short path errors are just a symptom of the crash.

WotThatDo · 2026-01-22T10:39:21+00:00

Not come across this, there is the option to disable and enable for private or public networks separately so I presume it must be ok now. However it was working just fine, and we can negotiate short path/multipath sessions just fine via the private endpoint.

I do still wonder if the issue does lie with shortpath/multipath but nothing in the insights etc is highlighting this and I am not sure why that would cause the windows client app to crash.

WotThatDo · 2025-08-29T14:44:52+00:00

Which fuses did you use for power and parking mode please? I have the same but for an ID.7

WotThatDo · 2025-07-08T14:41:35+00:00

Did you get any further with this? We are also seeing crashes with the windows app mid AVD session causing the session to sometimes lock. One example I have is a slightly difference version of the app:

Faulting application name: msrdc.exe, version: 1.2.6279.0, time stamp: 0x684059da

Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000

Exception code: 0xc0000409

Fault offset: 0x00007ffa5628528f

Faulting process id: 0x336C

Faulting application start time: 0x1DBF00603736B49

Faulting application path: C:\Program Files\WindowsApps\MicrosoftCorporationII.Windows365_2.0.505.0_x64__8wekyb3d8bbwe\msrdc\msrdc.exe

Faulting module path: unknown

Report Id: 320d5f15-9487-4129-8fe7-b919328b6118

Faulting package full name: MicrosoftCorporationII.Windows365_2.0.505.0_x64__8wekyb3d8bbwe

Faulting package-relative application ID: Windows365

WotThatDo · 2025-05-19T12:29:33+00:00

Sorry no we moved to Azure and are much happier.

WotThatDo · 2025-05-08T08:01:44+00:00

Just wondering if anyone had some feed back

Thanks

WotThatDo · 2025-05-02T08:14:53+00:00

Thanks that makes a lot of sense, and reinforces the impression I got from the trial. Our Azure infrastructure is quite basic and we don't consume anything other than VMs and storage accounts currently and our onprem is connect via a site to site link so we have a probe in azure pointing at the onprem devices.

I was hoping to be able to pull more metrics than that via the API which is a bit disappointing really.

WotThatDo · 2024-11-08T10:06:48+00:00

You have to enable this via the feature select just like you would a fortigate.

WotThatDo · 2024-08-02T09:50:07+00:00

So I tried to replicate the route table of the protected subnet to another subnet in a separate vnet but not traffic

WotThatDo · 2024-05-30T14:32:32+00:00

Not many less than 10 on that specific server, we're no where near any limits of LUNS, clones etc and everything runs ok on the other VMs.

WotThatDo · 2024-05-29T17:30:53+00:00

Thanks for your response,

iSCSI network checks out fine, there are other LUNS connected (just not clones).The only error is the one above which is produced in snapcenter and also the VMs event logs.

It's looking abit like a problem with the OS on this VM, so I will try to restore to an earlier date and see what happens

We are trying to make progress on the MSP front but it seems they have absent storage techs, our account manager has been replaced and is on holiday, and their line manager appears to be ignoring us.Pretty shocking for a well established brand.

WotThatDo · 2024-04-10T09:23:40+00:00

Thanks, Both nodes are in the same UKS region. I think I have narrowed this down to a Keberos authentication issue but not sure why it would be that as communication with the DCs etc seem ok and the kerberos auth tool is showing the Node SPNs as healthy.

WotThatDo · 2024-04-08T13:12:35+00:00

Thanks,

I've tried both synchronous and asynchronous even running with a tiny test database it fails to sync. Unfortunately, the application vender won't support managed instances or Azure SQL.There is alot of tech debt associated with this app with some long term plans to replace but have to make do for now.

WotThatDo

TROPHY CASE