Got up to Ryan Amusements using this without a single crash all in one play session.

Seems like this is a huge win for the gaming community!

Or just use DXVK.

Would you be willing to look into whether the same oversights are in the code for the original version of BioShock 2? So many bugs from the initial release back in 2010 were still present in the remaster that i have a feeling a lot of the crashes of the original may have the same root causes.

Originally posted by StreamWhenGuy:

Or just use DXVK.

This wouldn't solve the issue, as Bioshock 2 itself is the one passing the render layer bad information for the D3D11 crash, but yet again, here comes the 41% brigade to try and shill Linux to no end. Also, it wouldn't solve the FMOD or Memory Release crash which is what I mostly encountered.

Originally posted by dinosauriac:

Would you be willing to look into whether the same oversights are in the code for the original version of BioShock 2? So many bugs from the initial release back in 2010 were still present in the remaster that i have a feeling a lot of the crashes of the original may have the same root causes.

I had a cheat for Bioshock 2 a million years ago. Someone actually was recording back then when I was using it: https://youtu.be/dUABgYh9vxw

From what I remember, the game was very stable for the time. Albeit we were all using Windows 7 32-bit machines, so there's that.

May I ask what is the purpose of using the original Bioshock 2 over the remaster? I know there really isn't much different superficially, but internally, they have done a lot to fix the game's UE scripting issues.

Originally posted by Sophisticated Gumi-chan:

May I ask what is the purpose of using the original Bioshock 2 over the remaster?

The video you linked has probably the biggest reason, in that the remaster doesn't include multiplayer. That said, there's some rather annoying bugs with the remaster that take me out of the experience.

Environmental reverb effects are broken, to the point that even just pausing and unpausing the game will toggle reverb on and off (reverb seems to deactivate itself after leaving an area and never turns back on).

Many cubemap refelections were either reimplemented incorrectly or redone to be much more pronounced and distracting. Siren Alley is the most egregious one with the super reflective red flooring.

The reworking of the game's textures in general is a lot more haphazard than BioShock 1, leaving most of the originals as-is. This makes it all the more awkward that the pristine and squeaky clean vending machines from the first game's remaster show up in 2, when they're supposed to be rotting and grimey.

Yeah it's a small thing, but since you end up rummaging through trash cans so often in the game - the fact that they're the *wrong* trash cans irks me.

Originally posted by dinosauriac:

Originally posted by Sophisticated Gumi-chan:

May I ask what is the purpose of using the original Bioshock 2 over the remaster?

The video you linked has probably the biggest reason, in that the remaster doesn't include multiplayer. That said, there's some rather annoying bugs with the remaster that take me out of the experience.

Environmental reverb effects are broken, to the point that even just pausing and unpausing the game will toggle reverb on and off (reverb seems to deactivate itself after leaving an area and never turns back on).

Many cubemap refelections were either reimplemented incorrectly or redone to be much more pronounced and distracting. Siren Alley is the most egregious one with the super reflective red flooring.

The reworking of the game's textures in general is a lot more haphazard than BioShock 1, leaving most of the originals as-is. This makes it all the more awkward that the pristine and squeaky clean vending machines from the first game's remaster show up in 2, when they're supposed to be rotting and grimey.

Yeah it's a small thing, but since you end up rummaging through trash cans so often in the game - the fact that they're the *wrong* trash cans irks me.

Wow, the multiplayer still exists? I thought it died when they swapped it over from GFWL to Steamworks. When I hacked the game before, the only anti-cheat GFWL had was itself, which just guarded the process from debugging, and was so easy to defeat, a single byte patch killed it entirely and you could use a debugger again. I hope they at least turned on VAC or something for Bioshock 2, although I can't imagine the player base is large enough that it even warrants cheating, or if even anyone who wasn't around making UT2k4 cheats at the time would even know how to make a cheat for it.

That said, I'd be happy to take a look at a few crash dumps if you have them.

Go to Control Panel\System and Security\Security and Maintenance\Reliability Monitor and then find Bioshock2.exe. The reliability monitor groups its activity by day, so make sure you are looking at the right day of when you played Bioshock 2 that it crashed if you can't find Bioshock2.exe in the listing.

I need as many as you can find. What I need from each one is the following:

Fault Module Name, Exception Offset, Exception Code and the Exception Data.

Originally posted by Sophisticated Gumi-chan:

I'd be happy to take a look at a few crash dumps if you have them..

Annoyingly, the original game doesn't show in reliability monitor.

Went directly to Fontaine Futuristics just now, since it's a guaranteed crash seconds after loading in usually. Voila, it crashed. No error message or anything, just promptly closes itself as usual. Nothing in reliability monitor.

That said, I DO have 18 different crash .dmp files from my most recent playthrough. One or two might be from testing DXVK, but the rest are from playing without any modification. Some may actually be from last year, now that I take a second look at them..

https://drive.google.com/file/d/1n-lWdOE0rEJzE1TP9FTOFdaEcyrenr41/view?usp=drive_link

The most reliable crash scenarios are loading into Fontaine Futuristics or The Atlantic Express, or using certain guns constantly such as the 50cal / lasers. Another near-guaranteed one is meleeing the vacuum bots in Minerva's Den instead of shooting them, half the time it'll cause a crash.

I've swapped to doing a full playthrough on Remastered currently, and with the cheat table activated it really is way more stable. I've been actively trying to trigger crashes and haven't had it happen yet.

Whenever I go back to either original or remastered, I always avoid using the laser lancer and machinegun because firing them for too long is a good way to make the game kill itself, but have spent a couple hours using those exclusively with no issues when cheat's active. If something similar can be done for the original, that'd be amazing.

Originally posted by dinosauriac:

Annoyingly, the original game doesn't show in reliability monitor.

It's probably because of your subsequent paragraph.

Originally posted by dinosauriac:

That said, I DO have 18 different crash .dmp files from my most recent playthrough. One or two might be from testing DXVK, but the rest are from playing without any modification. Some may actually be from last year, now that I take a second look at them..

They must have some kind of debugging framework attached to the original Bioshock 2. These DMP files are usually very useful, because they capture the exact moment the crash happened, and then flush the RAM to disk. However, these seem to be what are called minidumps. It's basically the same information that should appear in Reliability History, however, it doesn't, because whatever debugging framework they're using is just catching the exception, flushing a dump to disk, and then fail fasting the program. It's astounding the amount of differences I find between the original and the Remastered. I remember so much hooplah that they just took the original Bioshock 2, recompiled it with nothing changed and released it on PC and it was really just a way for them to sell the same game again for console. I will look into the dumps and get back to you when I can.

EDIT: Here are my notes from the crash dumps you sent me:

bioshock2_708060_crash_2023_8_8T22_59_54C0.mdmp // 0xC06D007E The exception code 0xC06D007E is generated for a delay-loaded DLL that, when needed, could not be found by the OS.
bioshock2_708060_crash_2023_8_8T23_0_3C0.mdmp // 0xC06D007E The exception code 0xC06D007E is generated for a delay-loaded DLL that, when needed, could not be found by the OS.
bioshock2_708060_crash_2023_8_8T23_0_13C0 // 0xC06D007E The exception code 0xC06D007E is generated for a delay-loaded DLL that, when needed, could not be found by the OS.
bioshock2_708060_crash_2024_5_28T21_37_32C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.
bioshock2_708060_crash_2024_5_28T21_37_53C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.
bioshock2_708060_crash_2024_5_28T21_52_43C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.
bioshock2_708060_crash_2024_5_28T22_14_34C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.
bioshock2_708060_crash_2024_6_2T1_47_17C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.
bioshock2_708060_crash_2024_6_2T1_50_3C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.
bioshock2_708060_crash_2024_6_2T1_53_26C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.
bioshock2_708060_crash_2024_6_2T2_11_6C0.mdmp // 0xC06D007E The exception code 0xC06D007E is generated for a delay-loaded DLL that, when needed, could not be found by the OS.
bioshock2_708060_crash_2024_6_2T2_11_15C0.mdmp // 0xC06D007E The exception code 0xC06D007E is generated for a delay-loaded DLL that, when needed, could not be found by the OS.
bioshock2_708060_crash_2024_6_2T2_12_16C0.mdmp // 0xC06D007E The exception code 0xC06D007E is generated for a delay-loaded DLL that, when needed, could not be found by the OS.
bioshock2_708060_crash_2024_6_2T2_12_29C0.mdmp // 0xC06D007E The exception code 0xC06D007E is generated for a delay-loaded DLL that, when needed, could not be found by the OS.
bioshock2_708060_crash_2024_6_2T2_19_9C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.
bioshock2_708060_crash_2024_6_3T1_27_43C0.mdmp // 0xC0000005 Nullptr exception. No module or stack frame info in the dump, worthless.

Sorry to say, they're worth ♥♥♥♥♥♥♥♥♥. None of the info I need to figure out what caused the exception is in the minidumps, other than what was the problem, I need to know where in the PE the exception was caused so I can use IDA to go look at the disassembly and figure out potential solutions.

There is a way you could try and give me this information, however, it generally either requires running the game in Windowed mode (the remastered requires having a border on it, and for me that's a deal breaker) or run it in full screen with 2 monitors. You need to download and install Visual Studio 2022. Run it as admin, and go to Debug -> Attach to Process. Force a crash within the game, and then it will say something about the PDB missing, just ignore it, and click View Disassembly. If Bioshock2.exe has ASLR on (probably does) the addresses will be temporary, so then you will have to copy the address from Visual Studio's debugger to Cheat Engine's Memory View. Cheat Engine should be able to generate you a module + offset, typically in the fashion of Bioshock2.,exe+3FFFF or something.

Originally posted by dinosauriac:

The most reliable crash scenarios are loading into Fontaine Futuristics or The Atlantic Express, or using certain guns constantly such as the 50cal / lasers. Another near-guaranteed one is meleeing the vacuum bots in Minerva's Den instead of shooting them, half the time it'll cause a crash.

All these crashes are fixed in remaster, at least I can't recreate them given your notes.

Originally posted by dinosauriac:

I've swapped to doing a full playthrough on Remastered currently, and with the cheat table activated it really is way more stable. I've been actively trying to trigger crashes and haven't had it happen yet.

I did 3 complete start-to-finish playthroughs to test the table, and I wasn't able to crash the game at all. (I was only going to do one, but then I always have lock picking lawyer in the back of my mind saying "one more time, just to make sure it wasn't a fluke" which then turned into 2 more times.

https://youtu.be/wyDcQSRHs1s
https://youtu.be/-NYcjasparM
https://youtu.be/eR8hiqu5ZAo

And then for good measure, after playing for almost 2 hours and 45 minutes on one of the runs, I did a complete Minerva's Den playthrough.

https://youtu.be/DSyIfUDZu1I

0 crashes.

Originally posted by dinosauriac:

Whenever I go back to either original or remastered, I always avoid using the laser lancer and machinegun because firing them for too long is a good way to make the game kill itself, but have spent a couple hours using those exclusively with no issues when cheat's active. If something similar can be done for the original, that'd be amazing.

The laser caused the FMOD crash I noticed that other things caused it too, like the machine gun and such. Things that queue a ton of sounds rapidly.

Thanks for taking a look into it! Wonder if a lot of the differences might be from porting it off DX10 era UE3 to a more recent version? I had a quick go trying to capture the crashes...

Originally posted by Sophisticated Gumi-chan:

If Bioshock2.exe has ASLR on (probably does) the addresses will be temporary, so then you will have to copy the address from Visual Studio's debugger to Cheat Engine's Memory View.

Managed to do the steps outlined for VS, but I'm a bit new to using CheatEngine so not quite sure how to proceed with that last part. Had two crashes with different results...


The offending code entries I think:

I'm not really a programmer sadly, I've only dabbled a little bit. Here is the disassembly view for both crashes if it might be helpful...

https://drive.google.com/file/d/1M7qKc1PKSYll5xMqlYM0hdo_TAG6bCUg/view?usp=sharing

Edit: if those are temporary addresses maybe they're not of much use. sorry. I think I've figured out how to run an assembly scan, it's taking a long while though. Will report back.

Edit 2: searching for the 601F453E address didn't result anything in the assembly scan it looks like. Made sure to have the game process still active within the VS debugger while doing the search, maybe it's the wrong search idk.

I'm a bit out of my depth here :(

Originally posted by dinosauriac:

Thanks for taking a look into it! Wonder if a lot of the differences might be from porting it off DX10 era UE3 to a more recent version? I had a quick go trying to capture the crashes...

Originally posted by Sophisticated Gumi-chan:

If Bioshock2.exe has ASLR on (probably does) the addresses will be temporary, so then you will have to copy the address from Visual Studio's debugger to Cheat Engine's Memory View.

Managed to do the steps outlined for VS, but I'm a bit new to using CheatEngine so not quite sure how to proceed with that last part. Had two crashes with different results...

Bioshock2.exe: 0xC0000005: Access violation writing location 0x38F67000

Exception thrown at 0x601F453E (nvwgf2um.dll) in Bioshock2.exe: 0xC0000005: Access violation reading location 0x36AC0000.

The offending code entries I think:

565073D0 movdqa xmmword ptr [edi],xmm0

601F453E rep movs byte ptr es:[edi],byte ptr [esi]

Bioshock 2 uses UE2.5, which is basically a fork of the UT2k4 engine. The remake uses UE2.5 as well, they just implemented DX11 and redid all of the shaders, textures, and bumped a lot of the mesh poly count up, to probably what they had before shipping the console version. You may have heard of something like Donkey Kong Country's soundtrack "uncompressed" where they locate the original samples used to craft the song, and recreate it. It's a similar analogy to what they did for the remaster.

So like I mentioned before, the game probably uses ASLR (Address Space Layer Randomization) which introduced entropy into where the addresses are in virtual memory. This was done at the time as a shotgun wedding solution for people who couldn't be assed to properly handle buffers, and the people who had to deal with remote code execution. The idea being, if the attacker doesn't know where in memory a JMP ESP instruction is, they can't compromise the machine. They were wrong. If you're interested in knowing more about how attackers adapted to the 64-bit world, you can look up Return-oriented programming and how ROP gadgets work. You basically build in memory a bunch of NOPs to sled your way down to eventually the code you want to run, and this usually accomplished in tandem with a bunch of other exploits such as heap spraying, de-randomizing ASLR by forcing 32-bit PEs which ironically doesn't solve the thing it's trying to fix because of limited entropy, and the classic buffer overflow. Anyway, we're not here to teach hacking, I'm here to teach you debugging.

https://imgur.com/a/FVEiMzS

OK so there are 4 pictures here.

Picture 1: https://i.imgur.com/gS04wRo.png This is your classic Cheat Engine main window. So long as you don't have some crazy weird theme to Cheat Engine, I'd assume your window looks like mine. Click the button where the arrow is pointing. The window in Picture 2 will pop up.

Picture 2: https://i.imgur.com/IXFeFio.png This window is called the Memory Viewer. From here, press CTRL+G. The Goto Address subwindow that's also in the picture will appear. Paste the address you got from Visual Studio here.

Picture 3: https://i.imgur.com/DPKJnsy.png You are now viewing the memory area of the crash. To the left you can see ModulleName.Extension+Offset followed by the opcode bytes, followed by the assembly mnemonics. All of this is programmer jargon, pay no attention to it, but what you need to do now is read the mnemonic.

565073D0 movdqa xmmword ptr [edi],xmm0

As you can see here, the instruction attempted to MOVe Double Quad packed Aligned, from register XMM0 into the pointer located at register EDI. What probably happened was EDI contains an invalid pointer, and that is the result of your crash. However, this still isn't enough for me to launch an investigation on my end. I need the ModuleName.Extension+Offset. I noticed that nvwgf2um.dll is mentioned in your crashlog for some reason, that's a NVIDIA specific DLL, that shouldn't be thrown from Bioshock, it's usually thrown from your driver when something from the render queue was misaligned due to a timing issue. Say for example a bad overclock or a RAM timing issue.

This leads me to picture 4.

Picture 4: https://i.imgur.com/i2WJ8Ce.png While your cursor and the line you GOTO'd are highlighted in Picture 3, press CTRL+C. The dialog box in Picture 4 will appear. Press Copy. You should now have in your clipboard the information you see in front of you in the memory viewer. You should be able to paste it here.

Now, simple devil's advocate, why am I making you do all this, why don't I just play Bioshock 2 myself and do the same thing I did for the remaster as I did for Bioshock 2...

Well I'm sorry to say, but I played for almost an hour and I couldn't get it to crash. The graphics for the original are absolutely AWFUL. The phong lighting mixed with the extremely low resolution textures just make me cringe beyond absolute belief. I don't know if I need to hack some setting or whatever into Bioshock2SP.ini to get the textures to actually be high quality, but things like the Circus of Values are so pixelated, I can't even make out what the hell is on the bottom of them.

If you'd like, you can add me on Steam, and we can use Steam Remote Play for me to guide you through the debugging process further, so we can get to the root of your crash, as I feel even if you do get me the information I mentioned, it's just going to lead to the scenario where I'll probably need you to walk the callstack too and dump a few registers, because that's equally as complicated.

There's only very few assets that were redone for the remaster, the majority just have a simple sharpen filter on them, the only notable changes are assets ported from Bio1 Remastered and the merry go round in Dionysus Park which is an entirely new model. The characters and majority of the wall textures are identical. The hasty upscaling often makes some of the low resolution assets look worse, like a note might be slightly pixellated in the original but it's become an unreadable smear in the remaster.

Running the original at 4k res with texture fade distance tweaks, mipfade time and streaming distance resolves excess blur.

Originally posted by Sophisticated Gumi-chan:

If you'd like, you can add me on Steam, and we can use Steam Remote Play for me to guide you through the debugging process further, so we can get to the root of your crash

Might be worthwhile, can perhaps hit you up tomorrow?

I have saves from all over the game so usually just load to a different point if I hit a crash. It's not so much blocking me from progressing, as that it'd be great to try making a similar "patch" that you did for the remaster since the original is just as unstable if not worse. Anyway this is what I copied from the memory viewer...


There's a lot of ways to crash BioShock 2, I've just been doing the most easily repeatable one which is loading Fontaine Futuristics (gil's lab area) and walking towards one of the loading doors to a side room. At first I thought it might be the DX10 Detail Surfaces option, since it looks to be Nvidia-related - but same thing happens with that disabled.

Could maybe also look at triggering the same Fmod overload crash from machinegun / laser fire in the original?

Originally posted by dinosauriac:

Anyway this is what I copied from the memory viewer...

nvwgf2um.dll+CA453E - F3 A4 - repe movsb

Here's what I have from my nvwgf2um.dll.

nvwgf2um.dll+CA453E call dword ptr [edx+1Ch]

I'm super surprised that it just happened to have an instruction at the same offset, however, it's not the same as yours, which as I mentioned before, now we need to do the amazing thing of you sending me your DLL, and probably end up walking the callstack to figure out where in Bioshock2 it's calling this function from so we can figure out why it's crashing, and also crashing at repe movsb makes no sense. REPE means to REPEate the MOVe String word instruction X times by whatever is in the EDI register. As I mentioned before, this doesn't help me much, and I need the full function to scope out what's wrong here, and probably the callstack and register dumps.

Originally posted by dinosauriac:

There's a lot of ways to crash BioShock 2, I've just been doing the most easily repeatable one which is loading Fontaine Futuristics (gil's lab area) and walking towards one of the loading doors to a side room. At first I thought it might be the DX10 Detail Surfaces option, since it looks to be Nvidia-related - but same thing happens with that disabled.

Could maybe also look at triggering the same Fmod overload crash from machinegun / laser fire in the original?

I tried shooting the machine gun a ton of times, and nothing triggered for me.

EDIT: I managed to trigger some kind of crash, but even though Visual Studio was attached as the debugger, the game just failfast'd and I couldn't catch it.

The program '[0x7DB0] Bioshock2.exe' has exited with code 3221225477 (0xc0000005) 'Access violation'.

So that sucks.

EDIT2: OK, so good news? Reliability manager managed to catch the exception itself. Bioshock2.exe+822350 Code 0xC0000005.

When I look at the bit of memory it crashed at, it's crashing here:

.text:11122350 rep movsd

Which is similar, but not exactly the same as your crash. This crash seems to be related to thread interoperability.

hkIArchive::`RTTI Complete Object Locator'
hkIArchive::`vftable'

'TtAddJobBatch',0 ; DATA XREF: .text:11121E7B↑o
'TtNoJobAvailable',0 ; DATA XREF: sub_11123D50+266↑o
'TtfinishJob',0 ; DATA XREF: .text:11122007↑o
'TtGetNextJob',0 ; DATA XREF: sub_111220E0+2B↑o
'TtUnknownJobs',0 ; DATA XREF: sub_11122660+14E↑o
'TtCloth',0 ; DATA XREF: sub_11122660+12A↑o
'TtBehavior',0 ; DATA XREF: sub_11122660+106↑o
'TtAnimation',0 ; DATA XREF: sub_11122660+E2↑o
'TtCollision Query',0
; DATA XREF: sub_11122660+B7↑o
'TtPhysics',0 ; DATA XREF: sub_11122660+61↑o
; sub_11122660+8C↑o ...

The function it's crashing on is TtGetNextJob.

I don't know for certain as I couldn't inspect the memory with the debugger during the crash, however, the crash occurs here:

qmemcpy((void *)(*v11 + (--v11[2] << 7)), a3, 0x80u);

I think it's trying to either copy a segment of memory to an invalid segment of memory, or copy an invalid segment of memory, or both. I can't be sure. I could validate v11 here the same way I do for the remake crashes. I'd have to craft the assembly for it, and it's a super wild shot in the dark.

YOU ARE FREAKING SAVIOUR. Personally, on my personal computer i didn't catch a single crash in both versions, but on laptop, crash issue was abysmal. I still don't understand why it's so different on different hardware, might be pure (un)luck or some options/tweaking i forgot/overlooked or whatever.

Too bad that original version is still in sad state, but oh well, so much for multibillionaire companies to playtest their freaking games with crashdumps. Thanks for this one at the very least.

I added a Fix Reverb script, that fixes reverb from not working after you pause the game (or use a vending machine).

Fix Reverb definitely stops it toggling off whenever you enter a new area or use a menu, good stuff there. However, I'm wondering if there's actually something wrong with how reverb is being applied since it's overpoweringly loud (way more than the 2010 game).

Edit: the issue goes deeper - reverb is being applied to the soundtrack too. I don't mean radios in the world, I just had combat music echoing like crazy when testing in Siren Alley.