Does the Celeron do HyperThreading? If yes, then I guess there's some race condition that doesn't manifest on uniprocessor systems. That winmm result is quite stupid, it means that dosbox is in the middle of some call into any DLL. Of course, it's quite probable that it is opengl, which is currently being called. Unfortunately I didn't get any useful stack trace in that case. Very annoying.
I've had good results with these steps in gdb (you need a self-built SDL.dll for this):
a) find out which command the render thread is executing:
- load gdb as usual, start program, after the crash, enter: "thread 1", then "up" repeatedly until you get a line containing SendSyncCommand(<some hex number>, <some small integer>)
- I expect that small int value is 2 (init new mode) or 3 (deinit old mode). If you have built SDL yourself, another "up" should show you a source line with something like "SendSyncCommand(this, OGL_(DE)INIT);" on it
b) with that knowledge, let's find the crashing call:
- set a breakpoint at program start: "b main"
- start the program: "r"
- you get the prompt again. Now that SDL.dll is loaded, we can set the real breakpoint: "b SDL_ohqthread.h:474" for INIT, "b SDL_ohqthread.h:315" for DEINIT
- continue the program: "c"
- a little bit later, you should get the prompt again, this time at init or deinit. it's now up to you to decide: do you expect the crash right now, or will it work this time? "c"ontinue if you think the crash appears later
- now it's time for the real action: enter "n" repeatedly. it will single-step through the init function, showing you each source line before it is executed. Do not worry if it seens to jump back and forth, showing some lines twice - that's just a result of gcc optimization. Sometimes there will be phases where you are told something about that _winmm stuff, just continue doing "n" until you get the crash. The last shown source line before the crash is the bad one. To save typing, pressing Enter without any command will execute the last command again 😉
(If you know gdb well, you can redo these steps and print some variables at the place of the crash if you like.)