Re[2]: ZwQuerySystemInformation crash

NTDEV
1

> Functions written with try/finally/leave semantics can generally

completely avoid deeply nested conditionals (typical no nested if
statements at all), and provide single entry/single exit semantics,
which allow code reviewers to readily check resource
allocation/deallocation correctness. Just because some academic
pontificated 30 years ago ‘thou shalt not’ doesn’t really mean much in
the real world. Gotos are bad if they are used badly.

I’m with Mark on this one. I learned the evils possible with goto a
long time ago but there is no need to be dogmatic on the subject. That
doesn’t mean it isn’t useful when used in a
disciplined manner. As Mark mentioned, It makes it easy to write
functions in C that do not lose resources (and where it is easy to
check that the function can not lose resources).

Robert Newton

2

No I am referring to local function gotos, used precisely to improve the
logic flow/readability of a function, and more importantly to reduce the
complexity of error case handling, not global gotos resulting in an
incomprehensible mess. Like I said Gotos are bad if they are used badly.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Wednesday, December 07, 2005 6:34 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ZwQuerySystemInformation crash

If C/C++ allowed, as COBOL 68 did, you to specify any label
in any part of the program as the object of a goto statement,
would you consider its use to be a good idea? Especially
into other modules or into the middle of some function in
some other module in some library. I will presume not since
I know you are an experienced developer. I did in later
years begin to use ‘go to’ with the only object permitted
being the exit paragraph of a section that was being
‘performed’. This was not completely required, but it did
eliminate priming reads which ‘go to’-less programming in
Cobol requires.
Then, Cobol did not support any other form of structured
loops, so that was pretty much all there was available. I
understand that recent versions of Cobol have added more
structure, but any language that requires that all data be
global has problems that I left behind over 18 years ago.

P.S. I don’t want to go back to Cobol.

P.P.S. You must be using Word as your editor in Outlook. I
still use OE since it does both email and newsgroups where I
can save newsgroup messages in my email folders when I deem
them worthy or in some other way remarkable for their
usefullness or stupidity.

“Roddy, Mark” wrote in message
> news:xxxxx@ntdev…
> Well then the use of try/finally is equally broken as one may
> be substituted for the other.
>
> SEH has massive stack overhead, even in the limited case of
> try/leave/finally with no exception handler. It was the stack
> overhead, staring me in the face in the form of a double
> fault blue screen, that lead me to replace SEH usage in the
> kernel with gotos masquerading as SEH. Try using it in the
> lowest driver in a large stack of drivers and get back to me
> about your experience.
>
> Functions written with try/finally/leave semantics can
> generally completely avoid deeply nested conditionals
> (typical no nested if statements at all), and provide single
> entry/single exit semantics, which allow code reviewers to
> readily check resource allocation/deallocation correctness.
> Just because some academic pontificated 30 years ago ‘thou
> shalt not’ doesn’t really mean much in the real world. Gotos
> are bad if they are used badly.
>
>
> p.s. the next time that Outlook decides to replace SEH with
> SHE I am going to shoot it :slight_smile:
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
> Sent: Wednesday, December 07, 2005 5:20 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] ZwQuerySystemInformation crash
>
> According to K&R, page 57, it says in part: "If the test,
> expr2, is not
>
> present, it is taken as permanently true, so for (;;){ …}
> is an “infinite”
> loop, presumably to be broken by other means (such as a break
> or return).
> PC-Lint chokes on while(0) because it is a constant. I prefer the
> for(;:wink:
> { … break;} style, especially for a block where most tests
> require a break out, with cleanup to be done. Using SEH with
> just the try{}, leave; and __finally{} blocks is another
> solution in Microsoft centric drivers.
>
> The use of gotos is bad because it leaves no trace of how
> flow happened.
> If
> you work at writing without using ‘goto’ you will find that
> your design skills will improve and you will be able to think
> much more globally. I
>
> found this true over 30 years ago when using COBOL where ‘go
> to’ could go anywhere within the code. It was a big help in
> working with assembler and my later switch to C and even
> later C++. It makes you realize that having no way to trace
> code flow is a really bad idea.
>
> “Arlie Davis” wrote in message
> news:xxxxx@ntdev…
> > Any compiler (or linter) that chokes on “do { … } while(0)” is
> simply
> > broken. It’s 100% valid C. It’s also one of the more reliable ways
> to
> > make
> > macros that correctly handle “;” statement termination.
> >
> > – arlie
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
> Michal Vodicka
> > Sent: Wednesday, December 07, 2005 4:36 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] ZwQuerySystemInformation crash
> >
> > And now someone will point out preprocessor macros are evil :wink: Yes,
> this
> > is
> > the way to go; it can be even more readable than pure goto Done I
> > routinely use.
> >
> > As for while(0), I guess I have a rule in PC-lint options
> which turns
> this
> > warning off. Prefast doesn’t allow it?
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

3

Folks,

All your points are noted. Thanks.
The code blue screened even without the spin lock. The spin lock was
added to prevent possible buffer sharing issues because gBuffer is
global.

The try except was also added during debugging. I need to remove it.

Please tell me if how best to get the process name from the pid in the
kernel (one that does not involve undocumented calls and pageable code).
I did some googling and did not come up with anything.

Thanks,
-Charu.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, December 07, 2005 11:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ZwQuerySystemInformation crash

Charu Venkatraman wrote:

I have a function that determines processname from the process id
inside a tdi driver. The code seems to get the process name correctly
in most cases, but the problem is that after this function is called
‘n’ times, my system blue screens with the 7e error. The blue screen
appears to happen at random times, and does not depend on running any
particular process. The entire code snippet is given below. Can
someone give me pointers as to what could be going wrong?

#define MIN(a,b) ((a) > (b) ? (b) : (a))

/* Function to determine current process name in the kernel */

int MyTdi_GetCurrentProcessName(char *ProcessName)

{

ULONG cbBuffer = 0x10000; // declare initial size of buffer - 64

NTSTATUS Status;

PSYSTEM_PROCESS_INFORMATION pInfo;

KIRQL irql;

int ret = FALSE;

__try {

ULONG pid = (ULONG)PsGetCurrentProcessId();

DbgPrint(“MyTdi_GetCurrentProcessName\r\n”);

KeAcquireSpinLock(&ns_getprocname_lock, &irql);

THAT is your key problem. Once you acquire the spinlock, you run at an
elevated IRQL, and several of the interfaces you call (such as
ZwQuerySystemInformation and wcstombs) cannot be called at an elevated
IRQL. That will result in an eventual, although unpredictable, blue
screen.

I don’t understand why you acquire the spin lock at all. It doesn’t seem

to be necessary. And why do you convert back to ANSI? Why can’t you just

keep the Unicode name around?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

> I’m curious. How much is “massive”? i.e. if I add a __try … __finally round

the outside of a function, by how many bytes does it’s stack usage go up?

The local variable of type __SEH_Rec is added to the stack frame of each
function which has a __try statement in it.

This variable is IIRC 4 words:

  • Next link
  • pointer to __except_handler_3 piece of code
  • current __try frame number
  • pointer to a static compiler-generated frame table

Compile some code by command-line CL to assembly and look at it.

C++ exception handling is much worse in this. First of all, it adds the
overhead to each function built with Enable Unwind Semantics, even if there
is no “try” keyword in the function.

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

5

So now you know that porting the code from user mode - and
Alex Fedotov’s prototype you used is user-mode a la Nebbett

  • into kernel is not just cut/paste job:-)

Btw, his source does not work under w2k3s at all - I tried it on x64, but
there are notes on the web that it does not work on 32 bit box also.

Anyway.

I issued several “dt” in windbg of various depths against the address
returned by IoGetCurrentProcess and shamelessly hardcoded offsets.

The code is not version-independent (would not work on NT4, that’s
for sure), I did not try it on a 64-bit box etc., but this snippet helps me
a
lot during debugging on XP.

Version-dependent switches are easy to add though, I did not bother.

This is C++, mainly because I do want to have “const” qualifiers here.

Note that imageName is reported by windbg as char[16].

// ----------------------------------------------------------------------------
void GetCurrProcessImageNameAndPath(const char*& imageName, const WCHAR*&
imagePath) {
PEPROCESS pEprocess_ = IoGetCurrentProcess();
UINT_PTR pEprocess = (UINT_PTR)pEprocess_;
UINT_PTR imageName_ = pEprocess + 0x174;
imageName = (char*)imageName_;
UINT_PTR pPeb_ = pEprocess + 0x1b0;
UINT_PTR pPeb = *(UINT_PTR*)pPeb_;
UINT_PTR aProcessParameters, ProcessParameters, ImagePathName_;
if(pPeb) {
aProcessParameters = pPeb + 0x10;
ProcessParameters = *(UINT_PTR*)aProcessParameters;
ImagePathName_ = ProcessParameters + 0x38;
imagePath = ((PUNICODE_STRING)ImagePathName_)->Buffer;
} else {
imagePath = L"";
}
}

Typical results:

. . .
2005/12/03:17:27:37.814 00000004/8128cda8 [[kvdf/DriverEntry from
System/ (pid=4=0x4)
. . .
2005/12/03:17:27:38.034 0000088c/8121c020 [[kvdf/OnDeviceControl from
mytest.exe/C:_Test\mytest.exe (pid=2188=0x88c)
. . .
etc.

Hope it helps.

----- Original Message -----
From: “Charu Venkatraman”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, December 07, 2005 11:46 PM
Subject: RE: [ntdev] ZwQuerySystemInformation crash

Folks,

All your points are noted. Thanks.
The code blue screened even without the spin lock. The spin lock was
added to prevent possible buffer sharing issues because gBuffer is
global.

The try except was also added during debugging. I need to remove it.

Please tell me if how best to get the process name from the pid in the
kernel (one that does not involve undocumented calls and pageable code).
I did some googling and did not come up with anything.

Thanks,
-Charu.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, December 07, 2005 11:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ZwQuerySystemInformation crash

Charu Venkatraman wrote:

> I have a function that determines processname from the process id
> inside a tdi driver. The code seems to get the process name correctly
> in most cases, but the problem is that after this function is called
> ‘n’ times, my system blue screens with the 7e error. The blue screen
> appears to happen at random times, and does not depend on running any
> particular process. The entire code snippet is given below. Can
> someone give me pointers as to what could be going wrong?
>

> #define MIN(a,b) ((a) > (b) ? (b) : (a))
>
> /* Function to determine current process name in the kernel */
>
> int MyTdi_GetCurrentProcessName(char *ProcessName)
>
> {
>
> ULONG cbBuffer = 0x10000; // declare initial size of buffer - 64
>
> NTSTATUS Status;
>
> PSYSTEM_PROCESS_INFORMATION pInfo;
>
> KIRQL irql;
>
> int ret = FALSE;
>
> __try {
>
> ULONG pid = (ULONG)PsGetCurrentProcessId();
>
> DbgPrint(“MyTdi_GetCurrentProcessName\r\n”);
>
> KeAcquireSpinLock(&ns_getprocname_lock, &irql);
>

THAT is your key problem. Once you acquire the spinlock, you run at an
elevated IRQL, and several of the interfaces you call (such as
ZwQuerySystemInformation and wcstombs) cannot be called at an elevated
IRQL. That will result in an eventual, although unpredictable, blue
screen.

I don’t understand why you acquire the spin lock at all. It doesn’t seem

to be necessary. And why do you convert back to ANSI? Why can’t you just

keep the Unicode name around?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

> allocation/deallocation correctness. Just because some academic

pontificated 30 years ago ‘thou shalt not’ doesn’t really mean much in
the real world. Gotos are bad if they are used badly.

If that is an acceptable trade off so be it, but
that is usually a big show stopper for most folks.
So where is that pontific to declare that goto’s are
actually good???:slight_smile:

And now someone will point out preprocessor macros are evil :wink:
Everything is evil when abused. I bet you saw idiotic class hierarchies
that created more problems than they solved, or something else
of the same sort not explicitly mentioned by Dijkstra.

I use and even call them object-oriented) constructs like

int func(…) {
// this is a “local” ctor
HANDLE hSomething = AS_INVALID_HANDLE_AS_CAN_BE;
FILE* pFile = AS_INVALID_PFILE_AS_CAN_BE;
int irc = S_OK;
. . .
if() { irc = RC_VALUE_1; goto dtor; }
. . .
if() { irc = RC_VALUE_2; goto dtor; }
. . .
dtor:
// inverse the order, jic they depend on each other:
if(AS_INVALID_PFILE_AS_CAN_BE != pFile) {
fclose(pFile);
pFile = AS_INVALID_PFILE_AS_CAN_BE;
}
if(AS_INVALID_HANDLE_AS_CAN_BE != hSomething) {
CloseHandle(hSomething);
hSomething = AS_INVALID_HANDLE_AS_CAN_BE;
}
return irc;
}

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, December 07, 2005 7:37 PM
Subject: RE: [ntdev] ZwQuerySystemInformation crash

i’ve heard of something from 10’s to a few 100 bytes (esp on platforms
like IA64). There is another side affect from using SEH…the optimizer
is severely limited in what it can do inside the __try block. the
optimizer can’t know which instruction/call will throw an exception, so
it basically gives up. If that is an acceptable trade off so be it, but
that is usually a big show stopper for most folks.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Wednesday, December 07, 2005 4:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ZwQuerySystemInformation crash

Mark Roddy wrote:
> SEH has massive stack overhead, even in the limited case of
> try/leave/finally with no exception handler. It was the stack
> overhead,

I’m curious. How much is “massive”? i.e. if I add a__try … finally
round
the outside of a function, by how many bytes does it’s stack usage go
up?
Sure, I could measure it myself, but you must have already done that.

On a separate point, the replacement of try … __finally with macro
calls that look the same but have different semantics makes me nervous.

(What do I mean by different semantics? Consider what happens if a
maintainer inserts a return into the TRY … FINALLY block).

If you always maintain your stuff, it probably isn’t a problem but we
can all recall cases where later maintainers just thought they knew
what macros did without looking at the definitions because “it was
obvious
from the name”. I would fear that TRY and FINALLY are an accident
waiting to
happen (unless, as I said, you do your own maintenance).

Don

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Alex - You might also find helpful for xp sp2 in the lab …

PUNICODE_STRING GetImagePathName(VOID)
{
return *(PUNICODE_STRING *)((PUCHAR)(IoGetCurrentProcess()) + 0x1f4);
}

… typical output …

“(null)” - system process
“\Device\HarddiskVolume1\WINDOWS\system32\cmd.exe” - command prompt

… surprise this is stored in non paged pool.

Cheers :slight_smile:

“xxxxx@Home” wrote in message news:xxxxx@ntdev…
> So now you know that porting the code from user mode - and
> Alex Fedotov’s prototype you used is user-mode a la Nebbett
> - into kernel is not just cut/paste job:-)
>
> Btw, his source does not work under w2k3s at all - I tried it on x64, but
> there are notes on the web that it does not work on 32 bit box also.
>
> Anyway.
>
> I issued several “dt” in windbg of various depths against the address
> returned by IoGetCurrentProcess and shamelessly hardcoded offsets.
>
> The code is not version-independent (would not work on NT4, that’s
> for sure), I did not try it on a 64-bit box etc., but this snippet helps
> me a
> lot during debugging on XP.
>
> Version-dependent switches are easy to add though, I did not bother.
>
> This is C++, mainly because I do want to have “const” qualifiers here.
>
> Note that imageName is reported by windbg as char[16].
>
> // ----------------------------------------------------------------------------
> void GetCurrProcessImageNameAndPath(const char*& imageName, const WCHAR*&
> imagePath) {
> PEPROCESS pEprocess_ = IoGetCurrentProcess();
> UINT_PTR pEprocess = (UINT_PTR)pEprocess_;
> UINT_PTR imageName_ = pEprocess + 0x174;
> imageName = (char*)imageName_;
> UINT_PTR pPeb_ = pEprocess + 0x1b0;
> UINT_PTR pPeb = (UINT_PTR)pPeb_;
> UINT_PTR aProcessParameters, ProcessParameters, ImagePathName_;
> if(pPeb) {
> aProcessParameters = pPeb + 0x10;
> ProcessParameters = (UINT_PTR)aProcessParameters;
> ImagePathName_ = ProcessParameters + 0x38;
> imagePath = ((PUNICODE_STRING)ImagePathName_)->Buffer;
> } else {
> imagePath = L"";
> }
> }
>
> Typical results:
>
> . . .
> 2005/12/03:17:27:37.814 00000004/8128cda8 [[kvdf/DriverEntry from
> System/ (pid=4=0x4)
> . . .
> 2005/12/03:17:27:38.034 0000088c/8121c020 [[kvdf/OnDeviceControl from
> mytest.exe/C:_Test\mytest.exe (pid=2188=0x88c)
> . . .
> etc.
>
>
> Hope it helps.
>
>
>
>
> ----- Original Message -----
> From: “Charu Venkatraman”
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, December 07, 2005 11:46 PM
> Subject: RE: [ntdev] ZwQuerySystemInformation crash
>
>
> Folks,
>
> All your points are noted. Thanks.
> The code blue screened even without the spin lock. The spin lock was
> added to prevent possible buffer sharing issues because gBuffer is
> global.
>
> The try except was also added during debugging. I need to remove it.
>
> Please tell me if how best to get the process name from the pid in the
> kernel (one that does not involve undocumented calls and pageable code).
> I did some googling and did not come up with anything.
>
> Thanks,
> -Charu.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Wednesday, December 07, 2005 11:14 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] ZwQuerySystemInformation crash
>
> Charu Venkatraman wrote:
>
>> I have a function that determines processname from the process id
>> inside a tdi driver. The code seems to get the process name correctly
>> in most cases, but the problem is that after this function is called
>> ‘n’ times, my system blue screens with the 7e error. The blue screen
>> appears to happen at random times, and does not depend on running any
>> particular process. The entire code snippet is given below. Can
>> someone give me pointers as to what could be going wrong?
>>
>
>> #define MIN(a,b) ((a) > (b) ? (b) : (a))
>>
>> /* Function to determine current process name in the kernel */
>>
>> int MyTdi_GetCurrentProcessName(char *ProcessName)
>>
>> {
>>
>> ULONG cbBuffer = 0x10000; // declare initial size of buffer - 64
>>
>> NTSTATUS Status;
>>
>> PSYSTEM_PROCESS_INFORMATION pInfo;
>>
>> KIRQL irql;
>>
>> int ret = FALSE;
>>
>> __try {
>>
>> ULONG pid = (ULONG)PsGetCurrentProcessId();
>>
>> DbgPrint(“MyTdi_GetCurrentProcessName\r\n”);
>>
>> KeAcquireSpinLock(&ns_getprocname_lock, &irql);
>>
>
> THAT is your key problem. Once you acquire the spinlock, you run at an
> elevated IRQL, and several of the interfaces you call (such as
> ZwQuerySystemInformation and wcstombs) cannot be called at an elevated
> IRQL. That will result in an eventual, although unpredictable, blue
> screen.
>
> I don’t understand why you acquire the spin lock at all. It doesn’t seem
>
> to be necessary. And why do you convert back to ANSI? Why can’t you just
>
> keep the Unicode name around?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

8

> Alex - You might also find helpful for xp sp2 in the lab …
I am brave enough to use my hack [or yours, they are both
equally disgusting:-)] in free builds, with proper checks
(is it that same OS build /version I stole offsets from? do
I have “system” (and/or NULL) where I expect? etc.)

Have to check though.

After a couple of remote debugging sessions from 6pm till 8am
I’d rather have all possible BSODs in-house:-)

----- Original Message -----
From: “Lyndon J Clarke”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, December 09, 2005 3:11 PM
Subject: Re:[ntdev] ZwQuerySystemInformation crash

> Alex - You might also find helpful for xp sp2 in the lab …
>
> PUNICODE_STRING GetImagePathName(VOID)
> {
> return (PUNICODE_STRING )((PUCHAR)(IoGetCurrentProcess()) + 0x1f4);
> }
>
> … typical output …
>
> “(null)” - system process
> “\Device\HarddiskVolume1\WINDOWS\system32\cmd.exe” - command prompt
>
> … surprise this is stored in non paged pool.
>
> Cheers :slight_smile:
>
> “xxxxx@Home” wrote in message news:xxxxx@ntdev…
>> So now you know that porting the code from user mode - and
>> Alex Fedotov’s prototype you used is user-mode a la Nebbett
>> - into kernel is not just cut/paste job:-)
>>
>> Btw, his source does not work under w2k3s at all - I tried it on x64, but
>> there are notes on the web that it does not work on 32 bit box also.
>>
>> Anyway.
>>
>> I issued several “dt” in windbg of various depths against the address
>> returned by IoGetCurrentProcess and shamelessly hardcoded offsets.
>>
>> The code is not version-independent (would not work on NT4, that’s
>> for sure), I did not try it on a 64-bit box etc., but this snippet helps
>> me a
>> lot during debugging on XP.
>>
>> Version-dependent switches are easy to add though, I did not bother.
>>
>> This is C++, mainly because I do want to have “const” qualifiers here.
>>
>> Note that imageName is reported by windbg as char[16].
>>
>> // ----------------------------------------------------------------------------
>> void GetCurrProcessImageNameAndPath(const char& imageName, const WCHAR&
>> imagePath) {
>> PEPROCESS pEprocess_ = IoGetCurrentProcess();
>> UINT_PTR pEprocess = (UINT_PTR)pEprocess_;
>> UINT_PTR imageName_ = pEprocess + 0x174;
>> imageName = (char*)imageName_;
>> UINT_PTR pPeb_ = pEprocess + 0x1b0;
>> UINT_PTR pPeb = (UINT_PTR)pPeb_;
>> UINT_PTR aProcessParameters, ProcessParameters, ImagePathName_;
>> if(pPeb) {
>> aProcessParameters = pPeb + 0x10;
>> ProcessParameters = (UINT_PTR)aProcessParameters;
>> ImagePathName_ = ProcessParameters + 0x38;
>> imagePath = ((PUNICODE_STRING)ImagePathName_)->Buffer;
>> } else {
>> imagePath = L"";
>> }
>> }
>>
>> Typical results:
>>
>> . . .
>> 2005/12/03:17:27:37.814 00000004/8128cda8 [[kvdf/DriverEntry from
>> System/ (pid=4=0x4)
>> . . .
>> 2005/12/03:17:27:38.034 0000088c/8121c020 [[kvdf/OnDeviceControl from
>> mytest.exe/C:_Test\mytest.exe (pid=2188=0x88c)
>> . . .
>> etc.
>>
>>
>> Hope it helps.
>>
>>
>>
>>
>> ----- Original Message -----
>> From: “Charu Venkatraman”
>> To: “Windows System Software Devs Interest List”
>> Sent: Wednesday, December 07, 2005 11:46 PM
>> Subject: RE: [ntdev] ZwQuerySystemInformation crash
>>
>>
>> Folks,
>>
>> All your points are noted. Thanks.
>> The code blue screened even without the spin lock. The spin lock was
>> added to prevent possible buffer sharing issues because gBuffer is
>> global.
>>
>> The try except was also added during debugging. I need to remove it.
>>
>> Please tell me if how best to get the process name from the pid in the
>> kernel (one that does not involve undocumented calls and pageable code).
>> I did some googling and did not come up with anything.
>>
>> Thanks,
>> -Charu.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
>> Sent: Wednesday, December 07, 2005 11:14 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] ZwQuerySystemInformation crash
>>
>> Charu Venkatraman wrote:
>>
>>> I have a function that determines processname from the process id
>>> inside a tdi driver. The code seems to get the process name correctly
>>> in most cases, but the problem is that after this function is called
>>> ‘n’ times, my system blue screens with the 7e error. The blue screen
>>> appears to happen at random times, and does not depend on running any
>>> particular process. The entire code snippet is given below. Can
>>> someone give me pointers as to what could be going wrong?
>>>
>>
>>> #define MIN(a,b) ((a) > (b) ? (b) : (a))
>>>
>>> /* Function to determine current process name in the kernel */
>>>
>>> int MyTdi_GetCurrentProcessName(char *ProcessName)
>>>
>>> {
>>>
>>> ULONG cbBuffer = 0x10000; // declare initial size of buffer - 64
>>>
>>> NTSTATUS Status;
>>>
>>> PSYSTEM_PROCESS_INFORMATION pInfo;
>>>
>>> KIRQL irql;
>>>
>>> int ret = FALSE;
>>>
>>> __try {
>>>
>>> ULONG pid = (ULONG)PsGetCurrentProcessId();
>>>
>>> DbgPrint(“MyTdi_GetCurrentProcessName\r\n”);
>>>
>>> KeAcquireSpinLock(&ns_getprocname_lock, &irql);
>>>
>>
>> THAT is your key problem. Once you acquire the spinlock, you run at an
>> elevated IRQL, and several of the interfaces you call (such as
>> ZwQuerySystemInformation and wcstombs) cannot be called at an elevated
>> IRQL. That will result in an eventual, although unpredictable, blue
>> screen.
>>
>> I don’t understand why you acquire the spin lock at all. It doesn’t seem
>>
>> to be necessary. And why do you convert back to ANSI? Why can’t you just
>>
>> keep the Unicode name around?
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
>> ‘’
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
>> ‘’
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@bellsouth.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>