[ExtractStream] Re: Released: TyTool alpha #1.

[Michael Loftis]

---------------------- multipart/alternative attachment
There is a better tool for debugging, here's the URL to a copy I keep 
http://www.wgops.com/dbg_x86_4.0.18.0.exe , if you go to 
http://msdn.microsoft.com/ 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*c:\websymbols*http://msdl.microsoft.com/download/symbols 
-- replacing c:\websymbols 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:

> 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...
>
> 
>
> For anybody who's interested, here were the steps I took to find the 
> crash:
>
> 1. Load tytool.exe into VC++ and run it. Let it crash.
>
> 2. Look in the call stack to find the location where tytool called 
> into user32.dll
>
> 3. Set a breakpoint at the location from #2
>
> 4. Re-run the program.
>
> 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).
>
> (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).
>
> 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.
>
> 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).
>
> 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.).
>
> 9. Open tytool as resources-only in a second instance of VC++.
>
> 10. Get the window handle passed to SendMessage() from values pushed 
> onto the stack.
>
> 11. Open Spy++ (yet another MS tool) and find the window from #10.
>
> 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.
>
> 13. Type email describing the problem, including likely C source, 
> hoping that it will be of some use to the author.
>
> 
>
> -Don
>
> 
>


---------------------- multipart/alternative attachment
An HTML attachment was scrubbed...
URL: http://lists.merlins.org/archives/extractstream/attachments/5e37c1b3/attachment.html

---------------------- multipart/alternative attachment--