Does thread xx have function yy in call stack?

I have thread xx in a system call. I'd like to check if that thread has function Kernel32!WriteFile in its call stack programatically. Any tips or examples of how to do this?

I'm currently reading about the InitialStack member of the _KTHREAD struct, which might help.
LVL 4
jimstarAsked:
Who is Participating?
 
jkrCommented:
>>I don't see a reason why I can't just read it without suspending.

I don't see any neither in this case, just to make it clear ;o)

>>Is this a technical requirement?

Well, you need a thread handle. On the other hand, since you are already using native APIs, 'NtOpenThread()' will do the job also.
0
 
jkrCommented:
Is that call inside a file system driver? If so, you can examine the opcode of the IRP.
0
 
jimstarAuthor Commented:
It is, however I want to specifically know whether or not the kernel32 version of WriteFile was called, as the IRP could be from any number of user-mode functions. I can't rely on having injected any code into the process, so I'm stuck figuring it out out-of-process, such as by ReadProcessMemory.
0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
jimstarAuthor Commented:
Also, WriteFile is only one of several functions/operations I'll be monitoring, but it illustrates the point.
0
 
jkrCommented:
>>It is, however I want to specifically know whether or not the kernel32 version
>>of WriteFile was called

You won't be able to tell that from the call stack. Both calls will transfer the request to the driver thread, and therefore it won't show up on the stack, since it never was there. BTW, are you planning to do that programmatically? If so, keep in mind that examining the stack requires to suspend the thread, and that is something you really want to avoid in kernel space...
0
 
jimstarAuthor Commented:
Shouldn't that be done by the ntdll.dll stub? Something like:

ntdll!KeFastSystemCall
ntdll!NtWriteFile
Kernel32!WriteFile
MyApp.dll!DoWriteDataFile
MyApp.exe!MyStuff

From what I've seen in windbg, I thought the user-mode thread call stack stays as above until the syscall returns.
0
 
jimstarAuthor Commented:
And yes, I'd like to examine the thread's user mode call stack programatically to determine the specific Win32 api associated with file system activity. I can either do this from kernel mode (from within the FS driver), or via user mode (passing the IRP info to usermode, let my service query the target thread/process, and log the data).
0
 
jimstarAuthor Commented:
Also, if the user-mode thread is blocked on a system call, as long as my driver keeps the operation blocked in kernel mode, I should be able to examine the user-mode thread stack without worrying about it changing (although not certain on this point). I've read on some various sites that you have to suspend it, but I'm wondering if that is just because those cases can't count on the thread being blocked.
0
 
jkrCommented:
>>I thought the user-mode thread call stack stays as above until the syscall
>>returns.

Yes, that is how i should be. But that is a different thread. Yet examinig the call stack is documented (Matt Pietrek explains that in http://www.microsoft.com/msj/0497/hood/hood0497.aspx). However, if you are not in the same process, the requirement is to attach as a debugger, which is probably not what you want.
0
 
jkrCommented:
>>but I'm wondering if that is just because those cases can't count on the
>>thread being blocked.

That indeed is the reason. It is not really a good idea to examine a stack while a thread is running, since then the stack may change constantly. See also http://www.codeproject.com/threads/StackWalker.asp ("Walking the callstack")
0
 
jimstarAuthor Commented:
>> That indeed is the reason

In this particular case, though, since the thread will be blocked on a system call (that I control when it returns), I don't see a reason why I can't just read it without suspending.

>> if you are not in the same process, the requirement is to attach as a debugger

Is this a technical requirement? Or, a policy requirement? As long as I'm able to interpret the stack frames (not yet sure how to do this programatically), it would seem like I could just read the target process' memory (ReadProcessMemory in usermode, or ZwReadProcessMemory in kernel mode) at the base stack pointer indicated by the KTHREAD struct, and then walk the stack.

I'm reading the above articles, so perhaps it will become clear.
0
 
jimstarAuthor Commented:
Good discussion on this. I need to think about it some more.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.