This isnt anything specific to the code, if that were the case then it would fail on ALL machines this has been tested on, and not just 4 out of the 8.
Equally, if it wasn't anything specific to the code, then everyone would be reporting that their programs mysteriously fail on bank commands when run with debug enabled on a machine with integrated video. They're not, so either a huge number of people are very remiss or it *is* something specific to your code, even if it's not something obviously specific to your code or even related to the parts of your code which you would logically expect to be involved.
For instance, reading and/or writing out of bounds to a bank may crash and it may not. Just because you shouldn't do it, doesn't mean it will necessarily pop up and nicely report to you that you've done it. It may only do that under certain, improbable circumstances.
Another example, any Windows API stuff, kernel32, all that, can do very unpredictable things if you pass it a bad pointer or something like that. It won't necessarily crash on the command you would expect.
Furthermore, any libraries you use which may spawn off a new thread can cause unpredictable errors. You may find it crashing on those lines because they just happen to be the next lines you execute after doing something which will shortly trigger an error in another thread. The timing won't be precise because threading is inherently unpredictable.
Heaven knows if any of those examples could be of any use, but these are the kind of things which could happen, and if it's any of them, it will still come down to your code. All I can suggest is to give it a bit of Sherlock Holmes. Eliminate things. Block comment sections of code. Write to the debuglog at certain points, try calling timewasting functions which do nothing particular, to see if you can get the program to crash on different lines. Without code, all I can really suggest is trial and error.