| Date: | July 2, 2007 / year-entry #237 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070702-00/?p=26193 |
| Comments: | 24 |
| Summary: | If you use the Image File Execution Options registry key to force a program to run under the debugger, all the kernel does is insert the debugger in front of the command line. In other words, the CreateProcess function figure out what program is about to be run and checks the Image File Execution Options.... |
If you use the Image File Execution Options registry key to
force a program to run under the debugger,
all the kernel does is insert the debugger in front of the command line.
In other words, the
In particular, it doesn't do anything with the other parameters
to the
Specifically, if you specified the
And then eventually I realize, "Oh, right, the debugger is hidden." To unstick myself, I fire up a program like Spy to get the window handle of the hidden debugger and fire up a scratch copy of Notepad so I can make it do my bidding and show the window. ntsd -Ggx notepad <F12> Break instruction exception - code 80000003 (first chance) eax=7ffdf000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005 eip=7c901230 esp=00a1ffcc ebp=00a1fff4 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 ntdll!DbgBreakPoint: 7c901230 cc int 3 0:001> r esp=esp-4 0:001> ed esp 1 0:001> r esp=esp-4 0:001> ed esp 0x00010164 0:001> r esp=esp-4 0:001> ed esp eip 0:001> r eip=user32!showwindow 0:001> g 0:001> q
The first two commands push the value |
Comments (24)
Comments are closed. |
I frequently find myself having to do this for API calls (SendMessage, especially) that aren’t available on the command line. Isn’t there an easier way to call into Win32 (without VBA)?
Another handy call is for when the debugger itself is hosed (works in ntsd):
resp=@esp-8
ed @esp 0n{TargetPID}
g=kernel32!DebugActiveProcessStop
Just what is it that makes Notepad such a perfect designated debugger victim?
Make that ed @esp @eip 0n{TargetPID}
Er, why not just try again. Why go through all that manual command entering into the debugger when all you need to do is run it again without the SW_HIDE?
It’s single-threaded and straight-forward crud code.
"Just what is it that makes Notepad such a perfect designated debugger victim?"
My guess: it’s lightweight so it starts fast, and it’s in the PATH, so it’s fast to type the command line.
"Why go through all that manual command entering into the debugger when all you need to do is run it again without the SW_HIDE?"
This assumes that it’s easy to run it again exactly as it was just run. That may not be the case.
PingBack from http://blog.paulbetts.org/index.php/2007/07/02/do-you-know-how-raymond-chen-shows-hidden-windows/
Yes, but, I wonder why not cmd? or the venerable winver? There’s something about notepad
or just use winspy (http://www.catch22.net/software/winspypics.asp) and show the window
You can also use the .call command if you don’t want to fool around with the stack directly. For example:
0:001> .call user32!NtUserShowWindow(0x303e2, 6)
Thread is set up for call, ‘g’ will execute.
WARNING: This can have serious side-effects,
including deadlocks and corruption of the debuggee.
0:001> g
eax=7ffde000 ebx=00000000 ecx=00000000 edx=77c4f06d esi=00000000 edi=00000000
eip=77c02ea8 esp=01c3f7e0 ebp=01c3f80c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77c02ea8 cc int 3
KJK::Hyperion: I wondered this, and decided that Notepad’s more popular than Winver and has a main window. In fact, it’s got most elements of a Windows program (writing a Notepad replacement was a common project in Win32 programming books), and simpler code than Calc or Winmine. You can also change its title, or type something in and scan memory for it. Cmd has the whole console window thing, which it just annoying.
Kevin: what symbols are you using?
For sending random messages to windows: http://www.maxoutput.com/SendMsg.html
For modifying properties of random windows: http://nirsoft.net/utils/winexp.html
Ehtyar.
I admit I’m not real knowledgeable when it comes to Win32 debugging, but I got lost about the time ntsd was invoked.
I assume you’re connecting the debugger to Notepad, and then issuing commands to manually execute the ShowWindow API call, correct?
I’ve not heard of ntsd before. Does it come with Windows, or is it part of Visual Studio (which I have installed)?
It’s part of the "Debugging Tools for Windows".
Python (with the pywin32 package) works pretty well too:
import win32gui, win32con
win32gui.ShowWindow(0x5656, win32con.SW_SHOW)
I must say that’s a rather poor design on the kernel’s part, and
very easy to cause minor behavior changes when launched under debugger
– exactly those who would hide the bug you’re trying to find. Also,
this trick is non-trivial (= few would ever figure it out without
having the accurate magic spell from a great wizard).
Alternately, you could run ntsd as a debugging server:
ntsd -server tcp:port=1234 -gGW
And then connect with windbg:
windbg -remote tcp:server=localhost,port=1234
Also works for services that are not allowed to interact with the desktop. And across the network too (of course).
Kevin wrote:
You can also use the .call command if you don’t want to fool around with the stack directly. For example:
0:001> .call user32!NtUserShowWindow(0x303e2, 6)
^ Symbol not a function in ‘.call user32!NtUserShowWindow(0x303e2, 6)’
Raymond mentioned that you can do this if you have some other function with the same signature as the API that you’re trying to call, but that’s unlikely when you’re debugging Notepad.
Raymond wrote:
Yaniv Pessach wrote a program that takes a function name and a parameter list on the command line.
Personally I use a version of the Callfunc executable from Undocumented Windows 3.1 that I modified to work as a Win32 console application. Sadly I don’t have the exact source of the current version I use available – I tried and failed to add pagination to the dump command (I couldn’t work out how to wait for a keypress…)
I’m usually a lurker… but after seeing this (never thought of it before) I have to remark:
That’s awesome!
Thanks Raymond
Harold
[And what would be a better design? -Raymond]
Perhaps the debugger could use saved winposinfo for itself and pass on the startup info to the child process?
The debugger can choose to do whatever it likes. We’re talking about the design of Image File Execution Options here.
PingBack from http://www.debugtricks.com/?p=15
PingBack from http://blog.not-a-kernel-guy.com/2008/01/09/277