-=> Quoting Richard Glidden to All <=-

 RG> I've been having problems getting Watcom C/C++ v10.5.a to run
 RG> properly under OS/2.  Everything works perfect, EXCEPT for the 32-bit
 RG> OS/2 Debugger! :(  A bit of a pain, when you program as poorly as I do
 RG> at times... 
 RG> The problem that I'm having, is that as soon as you try to load the
 RG> debugger to debug a 32-bit OS/2 Application, OS/2 reports that "A
 RG> program in this session has encountered a problem and is unable to
 RG> continue."  When I display the register information, it says that the
 RG> problem is an "Access Violation in STD32.DLL", which is
apparently one
 RG> of the Watcom debugger's DLLs. 
 RG> I'm running on Warp Fullpack, with FP17 installed.  The debugger
 RG> works fine for 16-bit apps, but not for 32-bit apps.  It also works
 RG> fine for Windows and DOS applications, it's only the 32-bit OS/2
 RG> Applications that it seems to choke on... 
 RG> Anyone have any suggestions as to how to fix this little problem?

You may not like this at all: it works for me. Great news, eh? 

I do have some suggestions:

1) I am assuming that you are using the graphics-mode OS/2 PM debugger for 
OS/2 and the character-mode debugger for DOS programs, both of which 
(WD.EXE and WDW.EXE in WATCOM\BINP) state that they are "16-bit OS/2 
executable"s when invoked from a DOS session. There are files with the same 
names in WATCOM\BINW: WD.EXE appears to be a DOS program (since it runs) 
and WDW.EXE states that it is a "16-bit Windows executable" when invoked 
from a DOS session. You might want to check which versions you are running, 
just in case. 

2) Check your LIBPATH: mine includes "h:\watcom\binp\dll" directory: yours 
may be on a different drive, but if it isn't in LIBPATH then the error 
probably means OS/2 can't find STD32.DLL to load it. Although I have to say 
that "Access Violation in STD32.DLL" isn't exactly the error message I 
would expect to see if this were the case. 

3) Does the program run (in some sense) on its own or is it possible that 
it is doing this all by itself on startup? 

4) I have applied FP10; I have not applied FP17. I'm sure you're really 
happy to read that bit of news. (If you decide to back out FP17, be sure to 
tell all of us if this turns out to actually work.) Oh, my Warp didn't come 
with Windows (is not fullpack). This really should not affect an OS/2 
program, however. 

5) I just checked APPLYA.BAT (which applies the C_A patch), and STD32.DLL 
is NOT listed. This means it is not changed by the patch. 

6) The "Infobase" CD-ROM has a large set of tech support topics. Have you 
tried scanning through all of them to see if any apply?
`
--- Blue Wave/Max v2.12 [NR]