How get thread's context?

How can a driver read the CONTEXT of thread in Windows 2000?

ZwGetContextThread/NtGetContextThread only seem to exist in Windows XP...?


/ Hannes.

Mark
Mon Apr 18 22:34:10 CDT 2005

Hannes wrote:
> How can a driver read the CONTEXT of thread in Windows 2000?
>
> ZwGetContextThread/NtGetContextThread only seem to exist in Windows XP...?
>
>
> / Hannes.
NtGetContextThread appears to exist in w2k. I'm not sure if it is
publicly exported. This api does not appear to be in either the DDK or
the IFS kit, so it would appear that it is not meant for public consumption.

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Arkady
Tue Apr 19 02:41:54 CDT 2005

That publicly :) due to "Windows NT/2000 Native API Reference" by Gary
Nebbett ( p.125 )
Arkady

"Mark Roddy" <markr@hollistech.com> wrote in message
news:e$$plCJRFHA.164@TK2MSFTNGP12.phx.gbl...
> Hannes wrote:
>> How can a driver read the CONTEXT of thread in Windows 2000?
>>
>> ZwGetContextThread/NtGetContextThread only seem to exist in Windows
>> XP...?
>>
>>
>> / Hannes.
> NtGetContextThread appears to exist in w2k. I'm not sure if it is publicly
> exported. This api does not appear to be in either the DDK or the IFS kit,
> so it would appear that it is not meant for public consumption.
>
> --
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com

hannes
Tue Apr 19 11:45:03 CDT 2005

My question still stands.
How can I use NtGetContextThread - or ZwGetContextThread - in Windows 2000?
It's not in ntoskrnl.lib for Windows 2000 (open as text and search for
function name)

Is there any other way to get CONTEXT?

I have Gary Nebbet's book. I can not find the function in ntoskrnl.lib for
Windows 2000 (XP has it). Many functions in his book are not available in
Windows 2000, I wish he would state that more clearly.

/ Hannes.

Doron
Wed Apr 20 01:51:07 CDT 2005

more importantly, what are you trying to do with the context once you have
it? there might an easier, more documented way to do what you want.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Hannes" <hannes.news@nospam.nospam> wrote in message
news:7101AE0E-D3E9-4548-A5CA-F521A67C6667@microsoft.com...
> My question still stands.
> How can I use NtGetContextThread - or ZwGetContextThread - in Windows
> 2000?
> It's not in ntoskrnl.lib for Windows 2000 (open as text and search for
> function name)
>
> Is there any other way to get CONTEXT?
>
> I have Gary Nebbet's book. I can not find the function in ntoskrnl.lib for
> Windows 2000 (XP has it). Many functions in his book are not available in
> Windows 2000, I wish he would state that more clearly.
>
> / Hannes.
>
>

hannes
Wed Apr 20 12:37:03 CDT 2005

The CONTEXT is needed to produce complete crash dumps from our kernel mode
driver.
We'd like to include the state of each thread (or driver has 2-3 threads
running) in the crash dump, and so we need the CONTEXT of each thread by the
time of the crash.

(Currently, we only get the CONTEXT of the crashing thread, in
EXCEPTION_POINTERS. Would like to get the other thread(s) CONTEXT as well.)

Thanks,

/ Hannes.

Maxim
Wed Apr 20 13:03:22 CDT 2005

The kernel does crash dumps, not your driver. IIRC even the minimal dump
will contain the thread context.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Hannes" <hannes.news@nospam.nospam> wrote in message
news:4E2D04B6-469F-4CB9-8BB0-65E7249F1A64@microsoft.com...
> The CONTEXT is needed to produce complete crash dumps from our kernel mode
> driver.
> We'd like to include the state of each thread (or driver has 2-3 threads
> running) in the crash dump, and so we need the CONTEXT of each thread by the
> time of the crash.
>
> (Currently, we only get the CONTEXT of the crashing thread, in
> EXCEPTION_POINTERS. Would like to get the other thread(s) CONTEXT as well.)
>
> Thanks,
>
> / Hannes.

hannes
Wed Apr 20 17:51:02 CDT 2005

Nope, in my case the kernel does no crash dumping - we have the swap file
disabled.

For this reason, I'd need CONTEXT to produce the crash dumps myself.


/ Hannes.

hannes
Mon May 09 13:12:11 CDT 2005

"Mark Roddy" wrote:
> NtGetContextThread appears to exist in w2k. I'm not sure if it is
> publicly exported. This api does not appear to be in either the DDK or
> the IFS kit, so it would appear that it is not meant for public consumption.

'NtGetContextThread' only seems to exist in ntdll.lib. AFAIK, that's a
user-mode only library, only reachable in ntdll.dll - which I can/should not
use from my driver.

See Maxim's comment in this post
http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.development.device.drivers&mid=d13a06c0-85e6-474c-af08-8cc1c9dae310&sloc=en-us

Could it still be implemented in the kernel, and if so - how can I get to
it? Can I call an ntoskrnl function based on its name?

/ Hannes.

Maxim
Mon May 09 16:45:16 CDT 2005

> Could it still be implemented in the kernel, and if so - how can I get to
> it? Can I call an ntoskrnl function based on its name?

Debugging your driver on a testbed with pagefile enabled and fixing all bugs
seems to be by far more realistic way to go then trying to implement your own
context save mechanism.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

hannes
Mon May 09 18:44:12 CDT 2005

"Maxim S. Shatskih" wrote:
> Debugging your driver on a testbed with pagefile enabled and fixing all bugs
> seems to be by far more realistic way to go then trying to implement your own
> context save mechanism.

Trust me, I wish I could do just that! The tricky part is that our customers
may have very different network environments that we can possibly test. When
they DO see an issue, we need to find out why it crashed. It's also often
impossible and/or too expensive to do our debugging at the customer site.

At six-digit unit prices, our customers expect nothing less than outstanding
support and no down-time :-P

This is why I am so persistent in trying to collect crash and/or run-time
information OUTSIDE of our labs, on live customer nodes. Windows is a very
mature and versatile operating system, we just need a little help here and
there in using what it has to offer (and sometimes things it may not be
originally designed to offer).


Thanks,

/ Hannes.

Maxim
Mon May 09 19:43:03 CDT 2005

> At six-digit unit prices, our customers expect nothing less than outstanding
> support and no down-time :-P

At such prices, you can do all debugging at home on testbeds. Have you ever
reproed the issue on a testbed?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

hannes
Mon May 09 20:08:02 CDT 2005

"Maxim S. Shatskih" wrote:
> At such prices, you can do all debugging at home on testbeds. Have you ever
> reproed the issue on a testbed?

As an example, I found an issue last week that would only reproduce if you
followed 5 exact steps of restarts/reconfigurations on a certain item. Our
nodes have thousands of configurable items... ANyway, we were lucky to catch
this in our labs, and I did get a crash dump since we run some machines with
swap file enabled.

My point is, we got lucky there - this might as well happen at a customer
site. They will not know exactly what they did when the node "disappeared"
off the network, so it will be close to impossible for us to reproduce in our
lab, just based on verbal feedback from our customer.


It appears I could reiterate this forever: Not everything can be caught in
test labs.

I will have to give up here.


/ Hannes.