I second Valgrind. It's an industry known and maintained tool and it slows things down but not THAT MUCH.
I managed to load the Dolphin gamecube emulator on Valgrind. Yeah, it was slow. But it still worked. The point being, if I can manage Dolphin which needs a ~>3 GHZ processor to run, you should be able to run your game (with much less slow down).
Load your program with Valgrind, and walk away for a couple hours (or minutes). If necessary, at some fake user input into your program so that it engages enemies, and comment out any checks that would "end" the game so it just keeps running (even if you end up with negative score or whatever). The point there is, keep the game running until it crashes, so you don't have to be the one to physically be there and the the "patience game" waiting for your slower-than-usual game to finally trigger.
If you've got a memory leak that eventually kills Allegro/whatever, it'll show that leak as it happens.
corrupted build / version mismatch
That's the other route I'd definitely check (though Valgrind will show errors in library code too!). Because it really sounds like an error "that should never happen" so something is clearly broken somewhere. Perhaps I worded that poorly, but I mean to say, it's certainly not your typical scenario for a crash.
I'd definite do a CLEAN re-install of all Allegro libraries and even try a different version of Allegro in the case that the specific binary's shipped with NuGET were corrupted or something. (Which I've never heard of happening before but... heck, anything is possible.)
... There's no weird chance of a 32 verses 64-bit library/header mismatch, is there?
Another option is compiling the newest github version from scratch to ensure everything is built from exactly the same, non-mismatched, source code/headers/etc.