Building ros on ros RosBE2.2.1, 'ninja bootcd -j1' fails after breaking into the debugger '(ntoskrnl/ob/obhandle.c:2966) OB: Attempting to insert existing object', RosBE prompt logs 'out of disk space ENOENT ENOSPC,'

I performed this test on a Win8.1 laptop, not on my main XPSP3 OS, so don't compare any execution times to previous attempts. Using that system frees me from the necessity to have my main OS blocked, and also allows me to spend a bit more RAM to ros for those challenging scenarios.

Reproduction steps

• create VBox 4.3.12 VM with at least 2000MB of RAM spent to VM (you will need that much!)
• the virtual HDD should be at least 10GB (you will need that much)
• install ros into the VM, I used 0.4.15-dev-5188-gabaf0d1 GCC8.4.0 RosBEWin 2.2.1 here, I installed on FAT
• install git 2.10.0 from rapps
• install RosBE 2.2.1 (use a local copy, we don't have that in rapps yet), use C:\ros as the source folder
• switch desktop resolution to 1152x864 to have enough space for convenient working
• run RosBE2.2.1
• Run the taskmgr in the performance tab, and leave it running to observe resource consumption. Place it next to RosBE window
• now within the RosBE2.2.1 prompt do:
• 'prompt $T $P$G'
• 'git config --system http.sslverify false'
• 'git clone https://github.com/reactos/reactos.git'
• 'cd reactos' to enter the source tree. You should be in C:\ros\reactos now.
• 'git reset --hard abaf0d1' to master 2022-10-13 21:30 (commit 0.4.15-dev-5188-gabaf0d1) in your working-tree which is only RosBE2.2.1compatible and builds successfully on Windows
• 'configure'
• 'cd output-MinGW-i386'
• 'ninja bootcd -j1'

Expected result
after a few days it should return to the prompt having built a proper bootcd. No time requirements to fulfill. It just should complete the process.
Like it does on WinXPSP3

Observed result
after ~28hours and a progress of [3325/11029] compiled modules it broke into the debugger:

(ntoskrnl/ob/obhandle.c:2966) OB: Attempting to insert existing object B394E860



Entered debugger on embedded INT3 at 0x0008:0x805A30AE.

kdb:> bt

Eip:

<ntoskrnl.exe:1a30ae (:0 (DbgBreakPoint))>

Frames:

<ntoskrnl.exe:1320a9 (ntoskrnl/ps/process.c:767 (PspCreateProcess))>

<ntoskrnl.exe:1331cc (ntoskrnl/ps/process.c:1385 (NtCreateProcessEx))>

<ntoskrnl.exe:3fe5 (:0 (KiSystemCallTrampoline))>

<ntoskrnl.exe:1642d6 (ntoskrnl/ke/i386/traphdlr.c:1840 (KiSystemServiceHandler))>

<ntoskrnl.exe:3d9b (:0 (KiSystemService))>

<ntdll.dll:10384 (dll/ntdll/dispatch/i386/dispatch.S:251 (KiIntSystemCall))>

<kernel32.dll:16c0e (dll/win32/kernel32/client/proc.c:4697 (CreateProcessInternalA))>

<kernel32.dll:16d27 (dll/win32/kernel32/client/proc.c:4755 (CreateProcessA))>

<gcc.exe:6fe81>

<gcc.exe:7018b>

Couldn't access memory at 0x000006AC!

I could continue on the kdb-prompt and a few seconds after that the compilation stopped, telling me I would not have any space free on the drive
0.4.15-dev-5188-gabaf0d1_OBHANDLE.png
while in fact I still had more than 6GB free space on the drive:
0.4.15-dev-5188-gabaf0d1_OBHANDLE.log.7z (compressed log)
0.4.15-dev-5188-gabaf0d1_thereIsStillALotOfSpaceFree.png

I do remember exactly, that I have seen that exact symptom before already.
But I did not create a ticket back then. Because back then ros 0.4.15-dev-xxx-instability could be proven by much simpler tests still.