Sprinkle your code with printf's and see where the last one executes.

Are you 100% certain its not memory corruption? I'm out of ideas off the top of my head. If you want to bundle up all the code maybe I can look at it.

What version of Allegro are you using? I ask, because I've noticed on Windows and using 4.2 version, I get problems (lockups and such) with start up / shutdown....but is entirely random. I know it's not my code, as it's happened to several different programs made with this version of Allegro. It's really frustrating, and I haven't been able to isolate it. I can't really do anything to get it to do it all the time, so it's hard to report as an error. I think it has something to do with thread synchronization (possibly with the DirectX driver or the timer system?) I don't know about DURING program execution...I can't remember anything off hand. I just started using the 4.3 version of Allegro, so we'll see what happens with that.

I suggest trying the 4.3.10 version and see if it does it with it. There are SOME differences, but there is a compatibility layer it seems. For example: there is not a textprintf function, you must use textprintf_ex and such. That, to me, sucks because you don't get the transparent text with the text_mode(-1) option...as it is gone as well.:-/ The good thing is that you can still use these functions under the compatibility layer. I think they removed these because of issues with the true type fonts and such. I noticed issues with add on libs for 4.2 that used true type and those functions. If you don't have or want the 4.3.10 version of Allegro, I could compile it for you and we could both check to see if we could reproduce this "error" again.::)

I've had problems like these as well, and so did X-G's Cosmic Invaders program. I don't think it is directly caused by the code we're using for our programs. My guess is that the DX drivers on Windows for Allegro 4.2 have some kind of threading issue, but if they do, it's insanely hard to debug because it's so random.

The problems I've had include windows that are running normally (according to Windows), but are not receiving visual updates. If the window title bar is held and the window is dragged around, then the window updates again. This is reproducible fairly consistently for me with several of the example programs - exdbuf, and exflame do it, and probably more as well. Both use GFX_AUTODETECT as the first graphics driver to try, and the screen flashes several times while it's trying to find a driver that doesn't fail. I think the fact that the graphics driver fails to be set several times is the direct cause of why the little 320X200 window they finally open is all borked. That kind of problem is mainly with the example programs though.

The problem I have with my programs once in a while is pretty similar. The window will freeze without Windows detecting the program as non-responsive, but in this case, it can't be forced to visually update by moving the window.