Would it be possible to run this with the debug version (as described here) so that we could get more detailed logs on what’s going on here, as well as get the resolved callstack (UBA should be attempting to resolve it via collected stack pointers, and PDBs).
We haven’t tested against this Windows 11 Update just yet (just spoke with the domain SME), so we can give it a whirl on our end as well.
Crashing process is breakpad’s dump_syms.exe ran after linking any Linux binary.
Build “succeeds” because the .psym output is not essential to complete the build, but also means Linux debugging symbols will not be available.
UbaDetours.dll: +0x492e appears to be the detoured realloc, hypothesis is a ucrt allocation is being made somehow and later fed to mimalloc’s mi_realloc.
dump_syms has DIA as a dependency, which is likely the COM library seen in the callstack. Hypothesis is it’s now able to make a memory allocation bypassing mimalloc after KB5060842.
Thanks for giving that a try. Can you please rebuild a debug variant of this and provide the generated logs. This will give us more to work with whilst we setup an update test environment.
Thanks for the trace log - could you also please attach the initiating machine log and the corresponding session log (if the crash is appearing on a compute agent; it doesn’t seem to be the case however). Just viewing this there isn’t any extra detail. The UBA trace seems fine as it’s completed the link.
I also tried making a debug build of dump_syms to get a more insightful stack dump from there. There must be some uncommitted source changes because I can’t get the thing to build for Windows.
When referring to rebuilding in debug, I am referring to the core UBA applications (UbaCli, UbaAgent, UbaHost, UbaCommon). Dump_Syms will be breakpad, which I haven’t had to recompile actually - I can take a look at that separately.
I’ve forwarded over your patch to the SME of UBA ([mention removed] ).
This have been fixed in latest binaries in main. (I think it takes a while before they are submitted in github.. like 2-3 hours or something like that)
Hello! We are facing the same issue on our build agents that got this Windows update as well (Unreal Engine 5.5).
What would be the proper approach to apply this fix? Is it going to be another hotfix version for 5.5.xxx release, or should we try to manually get it from 5.6 main (which I assume could cause conflicts with 5.5 UBA version)?
And in case we need to manually apply it which files and .dlls should we rebuild (should it be the whole UBA)?
For posterity, the fixing change is here. For 5.5, you could try and use the 5.6 binaries for a local build. Short of this, you’d need to apply either the fix above (via [Content removed] or wait until we get a 5.5 binary patch in (I’ll work with Henrik to see if we can get this - at the very least we can host the binaries on the Practical Debugging UBA page).
Then edit UbaDetoursFunctionsMiMalloc.inl so `Detoured__realloc_base` is implemented as such:
void* Detoured__realloc_base(void* memblock, size_t size) { if (IsInMiMalloc(memblock)) return mi_realloc(memblock, size); else return True__realloc_base(memblock, size); }Then build just the UbaDetours target. The .dll is output at `Engine\Binaries\Win64\UnrealBuildAccelerator\x64\UbaDetours.dll`
Rebuilding UnrealBuildTool is also necessary so it copies this .dll into `Engine\Binaries\DotNET\UnrealBuildTool\runtimes\win-x64\native\UbaDetours.dll`
