Randomly reproducible bugcheck 0xF when using modern web-browsers

The mentioned bugcheck 0xF (SPIN_LOCK_ALREADY_OWNED) randomly occurs for me when testing any of the following web-browsers:

• R3dfox 128.14.1 ESR Windows XP build: https://github.com/Eclipse-Community/r3dfox/releases/download/v128.14.1-XP/r3dfox_XP-v128.14.1.win32.portable.7z.
• Firefox For Windows 7 REWORK 128.14.1 ESR Windows XP build: https://github.com/e3kskoy7wqk/Firefox-for-windows-7-REWORK/releases/download/debug/firefox-128.14.1.en-US.win32.installer.exe.
• Mypal 78.1.0 (Windows XP build): https://github.com/Feodor2/Mypal68/releases/download/78.1.0/mypal-78.1.0.en-US.win32.zip.
• Weolar's Chrome 115 for Windows XP (in the recent past): https://github.com/weolar/xpchrome/releases/download/20231121/M115xp.zip. (but it does no longer work neither on ReactOS nor on Windows XP+ because of inbuilt timebomb which was sheduled until August 2026 and especially prevents the browser from the proper work after that time).

The bugcheck occurs mostly when performing any usual activity with the mentioned browsers, mostly when opening a huge web-pages. According to the log, it mcomes from our tcpip driver.

In my case, I tested Firefox For Windows 7 REWORK 128.14.1 ESR on ReactOS 0.4.17-dev-966-gf06eace.

In the attached debug.log, there is bugcheck code:

*** Fatal System Error: 0x0000000f

                       (0xAEC308E4,0x00000000,0x00000000,0x00000000)

and the call stack which indicates the source of problem:

[?7hEip:

<ntoskrnl.exe:1b2e6a (sdk/lib/rtl/i386/debug_asm.S:45 (RtlpBreakWithStatusInstruction))>

Frames:

<ntoskrnl.exe:9c476 (ntoskrnl/ke/bug.c:1079 (KeBugCheckWithTf))>

<ntoskrnl.exe:9ca2a (ntoskrnl/ke/bug.c:1420 (KeBugCheckEx))>

<hal.dll:aa53 (ntoskrnl/include/internal/spinlock.h:34 (KfAcquireSpinLock))>

<tcpip.sys:1e800 (drivers/network/tcpip/tcpip/lock.c:19 (TcpipAcquireSpinLock))>

<tcpip.sys:1b06e (drivers/network/tcpip/tcpip/fileobjs.c:322 (AddrFileFree))>

<tcpip.sys:1b69c (drivers/network/tcpip/tcpip/fileobjs.c:295 (AddrSearchNext))>

<tcpip.sys:11a08 (drivers/network/tcpip/ip/transport/udp/udp.c:392 (UDPReceive))>

<tcpip.sys:560e (drivers/network/tcpip/ip/network/ip.c:174 (IPDispatchProtocol))>

<tcpip.sys:8f8b (drivers/network/tcpip/ip/network/receive.c:475 (ProcessFragment))>

<tcpip.sys:94ea (drivers/network/tcpip/ip/network/receive.c:634 (IPv4Receive))>

<tcpip.sys:95ef (drivers/network/tcpip/ip/network/receive.c:667 (IPReceive))>

<tcpip.sys:13ad1 (drivers/network/tcpip/datalink/lan.c:376 (LanReceiveWorker))>

<tcpip.sys:128db (drivers/network/tcpip/chew/workqueue.c:43 (ChewWorkItem))>

<ntoskrnl.exe:7b6bc (ntoskrnl/io/iomgr/iowork.c:24 (IopWorkItemCallback))>

<ntoskrnl.exe:44298 (ntoskrnl/ex/work.c:157 (ExpWorkerThreadEntryPoint))>

<ntoskrnl.exe:14623e (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup))>

<ntoskrnl.exe:16ab35 (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup))>

<ntoskrnl.exe:146211 (ntoskrnl/ps/thread.c:63 (PspUserThreadStartup))>

<ec835356>

Couldn't access memory at 0x57E58959! 

My investigation shows that it actually fails on KeAcquireSpinLock() call inside AddrFileFree(): https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/network/tcpip/tcpip/fileobjs.c;hb=8a5b9300c1cd7a9627727246d7d55ee0093a063f#l322, which, in its turn, is called from the AddrSearchNext(): https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/network/tcpip/tcpip/fileobjs.c;hb=8a5b9300c1cd7a9627727246d7d55ee0093a063f#l295 (DereferenceObject() is just an alias for the AddrFileFree(), defined here: https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/network/tcpip/include/titypes.h;hb=8a5b9300c1cd7a9627727246d7d55ee0093a063f#l24). It fails because inside AddrSearchNext(),  the global AddressFileListLock is also acquired before calling AddrFileFree(): https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/network/tcpip/tcpip/fileobjs.c;hb=8a5b9300c1cd7a9627727246d7d55ee0093a063f#l241, and inside AddrFileFree(), it's acquired again: https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/network/tcpip/tcpip/fileobjs.c;hb=8a5b9300c1cd7a9627727246d7d55ee0093a063f#l322, without releasing previous one. So the mentioned bugcheck occurs obviously because of the double acquire of the same lock, so it's not surprising to occur at all.

To fix it, the global AddressFileListLock spin lock must be released before calling Dereference() (AddrFileFree()), where it's also manipulated (acquired and released again). So as result, after applying the fix, the lock is properly acquired and released inside AddrSearchNext() first, and only then, it's acquired and released again inside AddrFileFree(). This should properly fix the problem (and it does), so the bugcheck should not occur any more, since acquire and release sequence becomes correct after applying the changes described above.

I already made a fix locally and will submit a new PR soon.