I've been investigating a problem where starting a Graphic-Forms app from within SLIME using the SBCL backend results in seemingly nothing but a hang.
What appears to be happening is that the message loop in GF is not even getting past the first call to the Windows get-message function. I fired up Winspector Spy, which is a utility for inspecting the window hierarchy, and saw that application windows are getting created. But since no messages are getting processed (except for maybe the very initial WM_NCCREATE or WM_NCCSIZE), the windows don't appear and obviously are non-functional.
This problem has something to do with the combination of SLIME and SBCL, since CLISP and SLIME work together ok as fas as GF is concerned. Also, running SBCL from a command prompt works, albeit that's not nearly as nice an environment.
So there are a couple workarounds right now (both assuming that you want to use SLIME, rather than the LispWorks IDE). The first is to switch to CLISP at least for the time being, as this is a configuration that works fine. The second is to run SBCL from a command prompt.
It's important to keep in mind that SBCL/Win32 is currently still a single-threaded Lisp like CLISP is, so in both cases, the SLIME REPL would be queueing requests until the message loop exits. When we see multi-threading support appear in those Lisps, then hopefully we can get back our REPL while our GF apps are running.
I've sent a query to the slime-devel list in the hopes of getting some pointers to possible solutions, and I will continue to investigate this problem myself as time allows.