The glitch seems to be related to either the VM config or the firewall. I changed the VM config toOriginally Posted by Kayaker
vmmouse.present = FALSE
svga.maxFullscreenRefreshTick = 5
and shut down the firewall. I should have done them one at a time but I got impatient.
Anyway, stepped into U32 ok. So far, so good. Or as you folks back East say, si tant, si bon. :-)
I'll say. Just ran into the problem you described where I got tangled up in VM garbage while tracing the kernel.
Did you ever find a solution to dealing with that? I backed out using the stack but went too far and activated the app I am tracing. I think you mentioned something about setting a BP as soon as you enter the kernel.
The problem with this app is that it uses a lot of win32k.sys processing windows. I ran through a waitforinputidle, or something like that, and I think that lead into the VM garbage.
You mean this?
http://www.woodmann.com/forum/showthread.php?15244-synchronization-issues
It was just a thought.
Yeah, that's the one...thanks. For some reason, other than a small interruption from the supposedly turned off firewall (I guess the driver keeps doing its thing), I had a lengthy session in the VM with no interruptions.
If I run into more crap, I'll explore the use of your TID method.
In my first venture, I tried to trace right from the mouse capture...bmsg hwnd 203 (WM_LBUTTONDBLCLK) but I got caught up in some hairy win32k stuff, and that lead to the VM stuff. Getting smarter on trek #2, I set a BP in shell32, where I had traced successfully in a non-VM situatation, and it was pretty clear sailing.
My mind is getting bent with object theory, stuff like SHITEMID lists and PIDLs, apparently pronounced 'piddle'. The IDL is the system's equivalent of a path, with structures beginning with the structure length and ending with a NULL entry to indicate the end of the list.
My BPX was on _ShellExecuteExA, which takes a pointer to a SHELLEXECUTEINFO structure. As you trace from there through shell32, it interacts with OLE 32, and Shlwapi to parse the path and create IDLs and objects. I am hoping it will sooner or later reveal a connection to the MFT structure in the NTFS file system via NTFS.sys.
I have already found such a connection via CreateFile to the filecache but it is too far along and the file location seems to have been located in the MFT already. I am trying to understand whether the handle retrieved by CreateFile comes after the MFT has been accessed or before. It seems that by the time CreateFile gets a handle for the file, the file is already loaded into memory.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762154%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb759784%28v=vs.85%29.aspx
If you look at the structure members you can see the file/directory parameters, etc.
Posting Permissions
Bookmarks