<html> <head> </head> <body> There is a better tool for debugging, here's the URL to a copy I keep <a class="moz-txt-link-freetext" href="http://www.wgops.com/dbg_x86_4.0.18.0.exe">http://www.wgops.com/dbg_x86_4.0.18.0.exe</a> , if you go to <a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/">http://msdn.microsoft.com/</a> you can also search for debugging tools for windows.  Thats for x86 hosts and targets.  Though if you've got KD, NTSD, or WinDbg running in remote mode on an Alpha or IA-64 it'll work fine. Quick hint, to get symbols remotely in Windbg (part of the package above) use SRV*<a class="moz-txt-link-freetext" href="c:\websymbols*http://msdl.microsoft.com/download/symbols">c:\websymbols*http://msdl.microsoft.com/download/symbols</a> -- replacing <a class="moz-txt-link-freetext" href="c:\websymbols">c:\websymbols</a> with a place to store the symbols locally.  I don't know if MSVC++ can load symbols like that from the symbol server or not (never tried it). Don Starr wrote: <blockquote type="cite" cite="mid:002301c205bb$b4f280d0$0d00a8c0@d..."> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 9"> <meta name="Originator" content="Microsoft Word 9"> <link rel="File-List" href="cid:filelist.xml@0...">  <style>  </style> <div class="Section1"> Actually, my disassembler kind of sucks. It’s the one built into MS Visual C++ (chide me all you want for using the MS tools, but who figured out the problem first? ;)  ). Anyway, the disassembler was choking when I looked at instructions above the first SendMessage call. There appears to be a little non-executable stuff just before the C function I described earlier. Looks like a table of addresses followed by some other data – maybe for a switch()? Hmmm… might want to investigate that…<o:p></o:p>   <o:p></o:p> For anybody who’s interested, here were the steps I took to find the crash:<o:p></o:p> 1. Load tytool.exe into VC++ and run it. Let it crash.<o:p></o:p> 2. Look in the call stack to find the location where tytool called into user32.dll<o:p></o:p> 3. Set a breakpoint at the location from #2<o:p></o:p> 4. Re-run the program.<o:p></o:p> 5. At each breakpoint (one that’s “OK”, one that crashes), look at the values in registers, what’s pushed onto the stack, and what OS functions are called (not necessarily in that order).<o:p></o:p> (the MS tool DEPENDS.EXE is very helpful here – it shows the load address, entry points, ordinals, and function names for any DLL you want, like USER32).<o:p></o:p> 6. Step through the function in tytool, “decompiling” in my head from the assembly code into likely C code. Fill in the parameters to OS APIs based on register contents.<o:p></o:p> 7. Fill in “other stuff” in the C function, based on what the entry and exit code for the function looks like (e.g. the 1kB auto-var buffer on the stack).<o:p></o:p> 8. Fill in “yet more other stuff” in the C function, based on params required by called functions, the values passed in those params, and more than a passing familiarity with C (e.g. the variable number of args, register preservation and re-use, etc.).<o:p></o:p> 9. Open tytool as resources-only in a second instance of VC++. <o:p></o:p> 10. Get the window handle passed to SendMessage() from values pushed onto the stack.<o:p></o:p> 11. Open Spy++ (yet another MS tool) and find the window from #10.<o:p></o:p> 12. Get info about the window from Spy++. Cross-reference to the dialog resource opened in #9. Discover that the target window is an edit control in a dialog.<o:p></o:p> 13. Type email describing the problem, including likely C source, hoping that it will be of some use to the author.<o:p></o:p>   <o:p></o:p> -Don<o:p></o:p>    </div> </blockquote> </body> </html>