So not really much of a question per se, but I'm somewhat hopeful this will help someone one day. Basically I have had a few rare edge cases where games (their launchers, updaters, etc) don't "play nice" on a drive pool.
One pretty known one is you can't reliably update or sometimes complete downloads for Windows Store / Xbox Games Pass for PC games on a Drive Pool. So the best solution is to just store those on the underlying drives. Or a more complex way is to create a vhdx on the pool, and mount that on startup. I abandoned this process because auto-mount tasks on start were unreliable.
Another and more recent issue was a really vague .NET error upon trying to launch Vermintide 2 (or its launcher rather), and now recently the upcoming Darktide game release. Also its launcher. Unsurprising that both are built similarly and have the same underlying issue.
Here's a .NET Runtime type 1026 error snippet:
Application: launcher.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileLoadException
at Launcher.WebpageControl.InitializeComponent()
at Launcher.WebpageControl..ctor()
Exception Info: System.Windows.Markup.XamlParseException
at System.Windows.Markup.WpfXamlLoader.Load(System.Xaml.XamlReader, System.Xaml.IXamlObjectWriterFactory, Boolean, System.Object, System.Xaml.XamlObjectWriterSettings, System.Uri)
at System.Windows.Markup.WpfXamlLoader.LoadBaml(System.Xaml.XamlReader, Boolean, System.Object, System.Xaml.Permissions.XamlAccessLevel, System.Uri)
at System.Windows.Markup.XamlReader.LoadBaml(System.IO.Stream, System.Windows.Markup.ParserContext, System.Object, Boolean)
at System.Windows.Application.LoadBamlStreamWithSyncInfo(System.IO.Stream, System.Windows.Markup.ParserContext)
at System.Windows.Application.LoadComponent(System.Uri, Boolean)
at System.Windows.Application.DoStartup()
at System.Windows.Application.<.ctor>b__1_0(System.Object)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
at System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame)
at System.Windows.Application.RunDispatcher(System.Object)
at System.Windows.Application.RunInternal(System.Windows.Window)
at System.Windows.Application.Run(System.Windows.Window)
at Launcher.App.Main()
And an accompanying generic Application Error (1000):
That path / D: being the drive pool, with X, Y, and Z being a pretty typical pool comprised of three NVMes. NTFS, default cluster sizes, etc.
Associated WER event:
Fault bucket 2257353757522315808, type 5
Event Name: CLR20r3
Response: Not available
Cab Id: 0
Problem signature:
P1: launcher.exe
P2: 1.0.524.0
P3: 62986a65
P4: Launcher
P5: 1.0.524.0
P6: 62986a65
P7: ac
P8: 32
P9: System.Windows.Markup.XamlParse
P10:
Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.1dd51168-9fc5-4a36-a0bc-9af7fa29d163.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.0d25c5e8-7112-4acf-af6c-6a3c7eb889e6.tmp.WERInternalMetadata.xml
WPR_initiated_DiagTrackMiniLogger_OneTrace_User_Logger_20221002_1_EC_0_inject.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.8ac1f13e-b0c0-4233-aac7-e62d5d127872.tmp.etl
WPR_initiated_DiagTrackMiniLogger_WPR System Collector_inject.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.a1360658-513c-4348-a0b1-63893be7c43f.tmp.etl
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.e2911cc9-68d1-43fd-9ae1-54d8ce9aca1a.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.82c6eb73-9351-41d2-8b8c-15f17e264241.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.58330270-c9d8-4b11-aa75-af747f668d82.tmp.xml
These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_launcher.exe_879a726c111c41b74fd6edbb8a2bb72073c9fa4_653db52e_6bcbded9-15e1-46ab-a0b0-54dcb52093e4
Analysis symbol:
Rechecking for solution: 0
Report Id: a3224c03-9aec-4d47-a204-1d09af62180d
Report Status: 268435456
Hashed bucket: e63b9d47e4b06efbef53bb485182ca20
Cab Guid: 0
Troubleshooting recommendations immediately take you to running .NET installer 4.7.2, and failing that, "repairing" .NET. This actually led to breaking my .NET installs completely, causing immediate errors on opening up even basic installers (few weeks ago), so I ended up reinstalling Windows back then
You can imagine my surprise when on a fresh OS deployment, the issue immediately reproduced itself with a clean install and only the bare mininimum requirements. At least Drivepool is amazing to get up and resuming where you left off, heh.
Anyway, rather annoyingly, they fail to take into account that 4.7.2 was superceded by built-ins on Windows 10 since some time early last year, with 4.8. Let alone being on Windows 11 22H2 now. So you actually cannot feasibly install 4.7.2 and if you manage to, you'd probably break something. So this kinda stuff just wastes a ton of your time in troubleshooting.
So the takeaway is that if you run into really odd anti-cheat failures, or inexplicable launch/post-install/update errors, it may relate to filesystem functions not working as expected (whatever esoteric calls or functions they may be making, or assuming results for). And these are probably quite poorly logged by the respective applications and host system by default.
That said, System.IO.FileLoadException should have been a decent hint... I feel pretty dumb. Unless that's just hindsight being 20/20 here.
So, while this is easy to reproduce, do you think is this a Drivepool thing to possibly look into, track, and fix? Let me know if you want the dumps.
Or is this isolated to Fatshark and the way they wrote their launcher in .NET 4.7.2? I don't mind raising this with them on their forums, but doubt it'd go far.
At the very least, I'm hoping this post will help someone else one day.
Question
kachunkachunk
Hey There,
So not really much of a question per se, but I'm somewhat hopeful this will help someone one day. Basically I have had a few rare edge cases where games (their launchers, updaters, etc) don't "play nice" on a drive pool.
One pretty known one is you can't reliably update or sometimes complete downloads for Windows Store / Xbox Games Pass for PC games on a Drive Pool. So the best solution is to just store those on the underlying drives. Or a more complex way is to create a vhdx on the pool, and mount that on startup. I abandoned this process because auto-mount tasks on start were unreliable.
Another and more recent issue was a really vague .NET error upon trying to launch Vermintide 2 (or its launcher rather), and now recently the upcoming Darktide game release. Also its launcher. Unsurprising that both are built similarly and have the same underlying issue.
Here's a .NET Runtime type 1026 error snippet:
And an accompanying generic Application Error (1000):
That path / D: being the drive pool, with X, Y, and Z being a pretty typical pool comprised of three NVMes. NTFS, default cluster sizes, etc.
Associated WER event:
Troubleshooting recommendations immediately take you to running .NET installer 4.7.2, and failing that, "repairing" .NET. This actually led to breaking my .NET installs completely, causing immediate errors on opening up even basic installers (few weeks ago), so I ended up reinstalling Windows back then
You can imagine my surprise when on a fresh OS deployment, the issue immediately reproduced itself with a clean install and only the bare mininimum requirements. At least Drivepool is amazing to get up and resuming where you left off, heh.
Anyway, rather annoyingly, they fail to take into account that 4.7.2 was superceded by built-ins on Windows 10 since some time early last year, with 4.8. Let alone being on Windows 11 22H2 now. So you actually cannot feasibly install 4.7.2 and if you manage to, you'd probably break something. So this kinda stuff just wastes a ton of your time in troubleshooting.
So the takeaway is that if you run into really odd anti-cheat failures, or inexplicable launch/post-install/update errors, it may relate to filesystem functions not working as expected (whatever esoteric calls or functions they may be making, or assuming results for). And these are probably quite poorly logged by the respective applications and host system by default.
That said, System.IO.FileLoadException should have been a decent hint... I feel pretty dumb. Unless that's just hindsight being 20/20 here.
So, while this is easy to reproduce, do you think is this a Drivepool thing to possibly look into, track, and fix? Let me know if you want the dumps.
Or is this isolated to Fatshark and the way they wrote their launcher in .NET 4.7.2? I don't mind raising this with them on their forums, but doubt it'd go far.
At the very least, I'm hoping this post will help someone else one day.
Link to comment
Share on other sites
1 answer to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.