I have found that our IGR implementation does not wipe user memory before booting the next ELF, which occasionally resulted in faulty behaviour. I spent so long, wondering why it seemed like very large portions of the OPL GUI's memory was getting corrupted after IGR, seemingly getting overwritten by other regions of itself. It seemed to be caused by (leftover) old code from the game getting called by OPL's code/old data causing the new code to misbehave. @[email protected] The pull request hasn't been merged yet, so I added the new fixes there. Here is something for you to play with, while waiting. Threads live (CreateThread) and die (DeleteThread), that is why. It's the normal lifecycle of threads. For this bug in particular, the main thread got changed, which was why the main thread's ID changed. It is possible to keep the same main thread alive by using it to call ExecPS2(), but we cannot do that easily because the main thread is not in our control. But there is nothing in the documentation that suggested that the main thread's ID will always be 1. FMCB/FHDB does not change the way the PS2's kernel works. Only OPL does that. The thread IDs will always change, as long as you run any software that creates and deletes threads. Here, it's because IGR will cause the main thread to change because we have no power over the original main thread, so we make the IGR thread the main thread. There is only one thread that has a fixed ID, which is the idle thread (ID 0). Actually, the system exists. It's just that (all?) disc-based games do not allow you to return to the browser. What we're doing for IGR, is to wrench control from the game and kill it. Most of the world did not get to experience the PSBB, but the DLCs should have that function. I know that POPS certainly did.