This is not a Snap problem, and it is not even an SMP problem. It is not fixable by QSINIT, or OS4. It is a startup conflict that happens just as the WPS starts up. It is more likely to happen when you have many things trying to start, all at the same time (all of the CALL and RUN statements in CONFIG.SYS, plus STARTUP.CMD, plus the startup sound, plus whatever is in your STARTUP folder. The more things that you have starting, the more likely you are to have the problem).
On my quad core machine, it seems that the problem lies in the early part of starting the WPS. Most of the time, the sound plays, and STARTUP.CMD shows the window, with no controls, and that is the end. Reboot usually succeeds. It seems that there is a "window of opportunity" where something goes wrong. If you can make the "window" happen when it doesn't matter, you have bypassed the problem. If it gets moved to a time when something else is affected, you have a problem.
Some supporting observations:
I made a VBox install of eCS 2.1. After the install, I was having the blue screen hang, about 4 out of 5 boots. I used the VBox controls to limit the machine to about 60% processor usage. I tried booting 20 times, with no hang. I put it back to 100%, and it was failing 4 out of 5 tries. Okay, so I finished my install, and setup, at 60% processor usage. This included adding a number of things that put entries into CONFIG.SYS. After all of that, I put it back to 100%, and had no more trouble. The additional entries in CONFIG.SYS slowed down the boot enough to get whatever was causing the problem to cause the problem at a time when it doesn't matter. Doing that with a real machine is a little harder.
Some things to try (any of these can cause, or bypass, the problem):
Put a file named AltF2on.$$$ in the root of the boot drive (this effectively does Alt-F2 without user intervention). Displaying the information slows the boot process a little, and sometimes it will change it enough to let it get past the problem (or, it can cause the problem if you don't have it).
Use
http://www.tavi.co.uk/os2pages/utils/delay.zip to insert a one, or two, second delay at the beginning of your CONFIG.SYS, and/or at the end. That should allow all BASEDEV and DEVICE statements to complete, before proceeding to the next step.
Use REXX Autostart
http://hobbes.nmsu.edu/download/pub/os2/util/wps/rxast1911.exe to delay starting the contents of the STARTUP folder. Unfortunately, on my system, this never gets started when I have the problem, so I assume that the problem lies in the CALL and RUN statements (but it is not caused by those).
I also use my Logical Config.Sys Sorter (LCSS)
http://hobbes.nmsu.edu/download/pub/os2/util/config/lcss-0-4-8.wpi which seems to help (at least on all of my systems). READ the instructions.
Of course, there may be other things that can case the problem, and there may be other things that can move the "window" far enough to prevent it. Good luck...
