Peb is zero .. even if PsLookupProcessByProcessId returns ok ..

Hi everybody,

this is my second attempt at getting some help in extracting the command
line parameters from a running process, this time with code. I have done my
homework but I am a new to systems programming … and I am stuck!

The following code gets invoked from a thread (PsCreateSystemThread).
PsLookupProcessByProcessId seems to succeed but the Peb is set to zero …
any idea?

ps: when PsLookupProcessByProcessId returns the value of “proc” is struct
_EPROCESS * 0xffa32880

void GetCommandLineFromPID (void *p)
{
PIDex * const pid = (PIDex*)p; (PIDex is a simple struct )

WCHAR* cmd;
PEPROCESS proc = 0;
PPEB peb = 0;

pid->st = PsLookupProcessByProcessId ((PVOID)pid->pid, &proc);

if (NT_SUCCESS(pid->st)) // st returns ok
{
peb = proc->Peb;

if (peb != 0) // this is NOK – peb is always zero
{
cmd = (WCHAR *)peb->ProcessParameters->CommandLine.Buffer;

if (cmd != 0)
DbgPrint( “[%lxh] Command Line: %ws\n”, CT, cmd );
}

ObDereferenceObject(proc);
}

KeSetEvent(&pid->evt, 6, FALSE);
PsTerminateSystemThread(0);
}


Marco

A system thread is created in context of system process. Which dont have any
kind of user mode control structures, hence not PEB. There are not
documented ways to do what you want from kernel mode. Also, you should treat
an EPROCESS as a opaque data type and not reads directly from it.

Dan

----- Original Message -----
From: “System”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, September 19, 2003 2:05 AM
Subject: [ntdev] Peb is zero … even if PsLookupProcessByProcessId returns
ok …

> Hi everybody,
>
> this is my second attempt at getting some help in extracting the command
> line parameters from a running process, this time with code. I have done
my
> homework but I am a new to systems programming … and I am stuck!
>
> The following code gets invoked from a thread (PsCreateSystemThread).
> PsLookupProcessByProcessId seems to succeed but the Peb is set to zero …
> any idea?
>
> ps: when PsLookupProcessByProcessId returns the value of “proc” is struct
> _EPROCESS * 0xffa32880
>
> void GetCommandLineFromPID (void p)
> {
> PIDex * const pid = (PIDex
)p; (PIDex is a simple struct )
>
> WCHAR* cmd;
> PEPROCESS proc = 0;
> PPEB peb = 0;
>
> pid->st = PsLookupProcessByProcessId ((PVOID)pid->pid, &proc);
>
> if (NT_SUCCESS(pid->st)) // st returns ok
> {
> peb = proc->Peb;
>
> if (peb != 0) // this is NOK – peb is always zero
> {
> cmd = (WCHAR *)peb->ProcessParameters->CommandLine.Buffer;
>
> if (cmd != 0)
> DbgPrint( “[%lxh] Command Line: %ws\n”, CT, cmd );
> }
>
> ObDereferenceObject(proc);
> }
>
> KeSetEvent(&pid->evt, 6, FALSE);
> PsTerminateSystemThread(0);
> }
>
> –
> Marco
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Dan

the PID I am passing to this function is of a user mode process, that is why
I expected a pointer to the user mode Ped to be returned.

>Also, you should treat an EPROCESS as a opaque data type and not reads
directly from it.

ok … but I really need the command line (long story) … any other
suggestion … or tip on how I should proceed?

thanks,

Marco

System ( S_1_5_18 at hotmail.com )

“Dan Partelly” wrote in message news:xxxxx@ntdev…
>
> A system thread is created in context of system process. Which dont have
any
> kind of user mode control structures, hence not PEB. There are not
> documented ways to do what you want from kernel mode. Also, you should
treat
> an EPROCESS as a opaque data type and not reads directly from it.
>
> Dan
>
> ----- Original Message -----
> From: “System”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Friday, September 19, 2003 2:05 AM
> Subject: [ntdev] Peb is zero … even if PsLookupProcessByProcessId returns
> ok …
>
>
> > Hi everybody,
> >
> > this is my second attempt at getting some help in extracting the command
> > line parameters from a running process, this time with code. I have done
> my
> > homework but I am a new to systems programming … and I am stuck!
> >
> > The following code gets invoked from a thread (PsCreateSystemThread).
> > PsLookupProcessByProcessId seems to succeed but the Peb is set to zero

> > any idea?
> >
> > ps: when PsLookupProcessByProcessId returns the value of “proc” is
struct
> > _EPROCESS * 0xffa32880
> >
> > void GetCommandLineFromPID (void p)
> > {
> > PIDex * const pid = (PIDex
)p; (PIDex is a simple struct )
> >
> > WCHAR* cmd;
> > PEPROCESS proc = 0;
> > PPEB peb = 0;
> >
> > pid->st = PsLookupProcessByProcessId ((PVOID)pid->pid, &proc);
> >
> > if (NT_SUCCESS(pid->st)) // st returns ok
> > {
> > peb = proc->Peb;
> >
> > if (peb != 0) // this is NOK – peb is always zero
> > {
> > cmd = (WCHAR *)peb->ProcessParameters->CommandLine.Buffer;
> >
> > if (cmd != 0)
> > DbgPrint( “[%lxh] Command Line: %ws\n”, CT, cmd );
> > }
> >
> > ObDereferenceObject(proc);
> > }
> >
> > KeSetEvent(&pid->evt, 6, FALSE);
> > PsTerminateSystemThread(0);
> > }
> >
> > –
> > Marco
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>

I see. Well, the EPROCESS structure is different between NT major versions,
so maybe you got a wrong
offset into the process structure.

You can use undocumented NtQueryInformationProcess() with ProcessBasicInfo
to get the PEB virtual address. (Its anyway always at a fixed, always the
same, virtual address in user mode address space )
PEB and PROCESS_PARAMETERS are also opaque,
so whatever you do, dont put the code into a production driver.

----- Original Message -----
From: “System”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, September 19, 2003 9:51 AM
Subject: [ntdev] Re: Peb is zero … even if PsLookupProcessByProcessId
returns ok …

> Dan
>
> the PID I am passing to this function is of a user mode process, that is
why
> I expected a pointer to the user mode Ped to be returned.
>
> >>Also, you should treat an EPROCESS as a opaque data type and not reads
> directly from it.
>
> ok … but I really need the command line (long story) … any other
> suggestion … or tip on how I should proceed?
>
> thanks,
>
> Marco
> –
> System ( S_1_5_18 at hotmail.com )
>
> “Dan Partelly” wrote in message
news:xxxxx@ntdev…
> >
> > A system thread is created in context of system process. Which dont have
> any
> > kind of user mode control structures, hence not PEB. There are not
> > documented ways to do what you want from kernel mode. Also, you should
> treat
> > an EPROCESS as a opaque data type and not reads directly from it.
> >
> > Dan
> >
> > ----- Original Message -----
> > From: “System”
> > Newsgroups: ntdev
> > To: “Windows System Software Devs Interest List”
> > Sent: Friday, September 19, 2003 2:05 AM
> > Subject: [ntdev] Peb is zero … even if PsLookupProcessByProcessId
returns
> > ok …
> >
> >
> > > Hi everybody,
> > >
> > > this is my second attempt at getting some help in extracting the comma
nd
> > > line parameters from a running process, this time with code. I have
done
> > my
> > > homework but I am a new to systems programming … and I am stuck!
> > >
> > > The following code gets invoked from a thread (PsCreateSystemThread).
> > > PsLookupProcessByProcessId seems to succeed but the Peb is set to
zero
> …
> > > any idea?
> > >
> > > ps: when PsLookupProcessByProcessId returns the value of “proc” is
> struct
> > > _EPROCESS * 0xffa32880
> > >
> > > void GetCommandLineFromPID (void p)
> > > {
> > > PIDex * const pid = (PIDex
)p; (PIDex is a simple struct )
> > >
> > > WCHAR* cmd;
> > > PEPROCESS proc = 0;
> > > PPEB peb = 0;
> > >
> > > pid->st = PsLookupProcessByProcessId ((PVOID)pid->pid, &proc);
> > >
> > > if (NT_SUCCESS(pid->st)) // st returns ok
> > > {
> > > peb = proc->Peb;
> > >
> > > if (peb != 0) // this is NOK – peb is always zero
> > > {
> > > cmd = (WCHAR *)peb->ProcessParameters->CommandLine.Buffer;
> > >
> > > if (cmd != 0)
> > > DbgPrint( “[%lxh] Command Line: %ws\n”, CT, cmd );
> > > }
> > >
> > > ObDereferenceObject(proc);
> > > }
> > >
> > > KeSetEvent(&pid->evt, 6, FALSE);
> > > PsTerminateSystemThread(0);
> > > }
> > >
> > > –
> > > Marco
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> > > 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@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

The PEB layout is fairly stable now, although technically you should
never make assumptions about it – it’s strictly an OS internal
structure, and you are tying your driver to an OS version, in a manner
that will likely cause problems later, if the layout changes.

Personally, I would go ahead and use the CommandLine stuff from the PEB.
However, you’re doing it wrong. If you are writing this function to run
in k-mode, you must first attach to the process (in order to map its VM
address space), and you must use appropriate means to safely lock and
probe user-mode pages. All of the PEB, including the CommandLine field
and the string data that CommandLine.Buffer refers to, are stored in
user-mode data pages, not in kernel-mode. Simply dereferencing a
user-mode pointer in kernel-mode gets you an automatic F. There are
lots of references on how to safely read user-mode data.

If you do this, you MUST do some strict validation on the string length,
etc., so that you stand a chance of being a well-behaved driver, if your
driver gets loaded on a platform where CommandLine has changed or moved.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of System
Sent: Friday, September 19, 2003 2:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Peb is zero … even if PsLookupProcessByProcessId
returns ok …

Dan

the PID I am passing to this function is of a user mode process, that is
why I expected a pointer to the user mode Ped to be returned.

>Also, you should treat an EPROCESS as a opaque data type and not reads
directly from it.

ok … but I really need the command line (long story) … any other
suggestion … or tip on how I should proceed?

thanks,

Marco

System ( S_1_5_18 at hotmail.com )

“Dan Partelly” wrote in message
news:xxxxx@ntdev…
>
> A system thread is created in context of system process. Which dont
> have
any
> kind of user mode control structures, hence not PEB. There are not
> documented ways to do what you want from kernel mode. Also, you should
treat
> an EPROCESS as a opaque data type and not reads directly from it.
>
> Dan
>
> ----- Original Message -----
> From: “System”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Friday, September 19, 2003 2:05 AM
> Subject: [ntdev] Peb is zero … even if PsLookupProcessByProcessId
> returns ok …
>
>
> > Hi everybody,
> >
> > this is my second attempt at getting some help in extracting the
> > command line parameters from a running process, this time with code.

> > I have done
> my
> > homework but I am a new to systems programming … and I am stuck!
> >
> > The following code gets invoked from a thread
> > (PsCreateSystemThread). PsLookupProcessByProcessId seems to succeed

> > but the Peb is set to zero

> > any idea?
> >
> > ps: when PsLookupProcessByProcessId returns the value of “proc” is
struct
> > _EPROCESS * 0xffa32880
> >
> > void GetCommandLineFromPID (void p)
> > {
> > PIDex * const pid = (PIDex
)p; (PIDex is a simple struct )
> >
> > WCHAR* cmd;
> > PEPROCESS proc = 0;
> > PPEB peb = 0;
> >
> > pid->st = PsLookupProcessByProcessId ((PVOID)pid->pid, &proc);
> >
> > if (NT_SUCCESS(pid->st)) // st returns ok
> > {
> > peb = proc->Peb;
> >
> > if (peb != 0) // this is NOK – peb is always zero
> > {
> > cmd = (WCHAR *)peb->ProcessParameters->CommandLine.Buffer;
> >
> > if (cmd != 0)
> > DbgPrint( “[%lxh] Command Line: %ws\n”, CT, cmd );
> > }
> >
> > ObDereferenceObject(proc);
> > }
> >
> > KeSetEvent(&pid->evt, 6, FALSE); PsTerminateSystemThread(0);
> > }
> >
> > –
> > Marco
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@rdsor.ro 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@sublinear.org To
unsubscribe send a blank email to xxxxx@lists.osr.com

>> and you must use appropriate means to safely lock

> and probe user-mode pages

It really depends at what IRQL levels you want to access those pages. At
PASSIVE only access is not required to
lock them in any way.

Dan

----- Original Message -----
From: “Arlie Davis”
To: “Windows System Software Devs Interest List”
Sent: Friday, September 19, 2003 5:21 PM
Subject: [ntdev] Re: Peb is zero … even if PsLookupProcessByProcessId
returns ok …

> The PEB layout is fairly stable now, although technically you should
> never make assumptions about it – it’s strictly an OS internal
> structure, and you are tying your driver to an OS version, in a manner
> that will likely cause problems later, if the layout changes.
>
> Personally, I would go ahead and use the CommandLine stuff from the PEB.
> However, you’re doing it wrong. If you are writing this function to run
> in k-mode, you must first attach to the process (in order to map its VM
> address space), and you must use appropriate means to safely lock and
> probe user-mode pages. All of the PEB, including the CommandLine field
> and the string data that CommandLine.Buffer refers to, are stored in
> user-mode data pages, not in kernel-mode. Simply dereferencing a
> user-mode pointer in kernel-mode gets you an automatic F. There are
> lots of references on how to safely read user-mode data.
>
> If you do this, you MUST do some strict validation on the string length,
> etc., so that you stand a chance of being a well-behaved driver, if your
> driver gets loaded on a platform where CommandLine has changed or moved.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of System
> Sent: Friday, September 19, 2003 2:51 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Peb is zero … even if PsLookupProcessByProcessId
> returns ok …
>
>
> Dan
>
> the PID I am passing to this function is of a user mode process, that is
> why I expected a pointer to the user mode Ped to be returned.
>
> >>Also, you should treat an EPROCESS as a opaque data type and not reads
> directly from it.
>
> ok … but I really need the command line (long story) … any other
> suggestion … or tip on how I should proceed?
>
> thanks,
>
> Marco
> –
> System ( S_1_5_18 at hotmail.com )
>
> “Dan Partelly” wrote in message
> news:xxxxx@ntdev…
> >
> > A system thread is created in context of system process. Which dont
> > have
> any
> > kind of user mode control structures, hence not PEB. There are not
> > documented ways to do what you want from kernel mode. Also, you should
> treat
> > an EPROCESS as a opaque data type and not reads directly from it.
> >
> > Dan
> >
> > ----- Original Message -----
> > From: “System”
> > Newsgroups: ntdev
> > To: “Windows System Software Devs Interest List”
> > Sent: Friday, September 19, 2003 2:05 AM
> > Subject: [ntdev] Peb is zero … even if PsLookupProcessByProcessId
> > returns ok …
> >
> >
> > > Hi everybody,
> > >
> > > this is my second attempt at getting some help in extracting the
> > > command line parameters from a running process, this time with code.
>
> > > I have done
> > my
> > > homework but I am a new to systems programming … and I am stuck!
> > >
> > > The following code gets invoked from a thread
> > > (PsCreateSystemThread). PsLookupProcessByProcessId seems to succeed
>
> > > but the Peb is set to zero
> …
> > > any idea?
> > >
> > > ps: when PsLookupProcessByProcessId returns the value of “proc” is
> struct
> > > _EPROCESS * 0xffa32880
> > >
> > > void GetCommandLineFromPID (void p)
> > > {
> > > PIDex * const pid = (PIDex
)p; (PIDex is a simple struct )
> > >
> > > WCHAR* cmd;
> > > PEPROCESS proc = 0;
> > > PPEB peb = 0;
> > >
> > > pid->st = PsLookupProcessByProcessId ((PVOID)pid->pid, &proc);
> > >
> > > if (NT_SUCCESS(pid->st)) // st returns ok
> > > {
> > > peb = proc->Peb;
> > >
> > > if (peb != 0) // this is NOK – peb is always zero
> > > {
> > > cmd = (WCHAR *)peb->ProcessParameters->CommandLine.Buffer;
> > >
> > > if (cmd != 0)
> > > DbgPrint( “[%lxh] Command Line: %ws\n”, CT, cmd );
> > > }
> > >
> > > ObDereferenceObject(proc);
> > > }
> > >
> > > KeSetEvent(&pid->evt, 6, FALSE); PsTerminateSystemThread(0);
> > > }
> > >
> > > –
> > > Marco
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@rdsor.ro 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@sublinear.org 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@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Right, sure. I’m just emphasizing that accessing user-mode data is
something you have to be aware of doing – it isn’t “just a pointer”.
If you know for sure you’re running at passive, and you know that you
have the right process attached already (which is doubtful, since you
need to look up the process to begin with), then you can dereference the
pointer, probably inside an SEH __try/__except block.

But you knew all that already, cuz you’re reading this on NTDEV.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Partelly
Sent: Friday, September 19, 2003 10:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Peb is zero … even if PsLookupProcessByProcessId
returns ok …

> and you must use appropriate means to safely lock
> and probe user-mode pages

It really depends at what IRQL levels you want to access those pages.
At PASSIVE only access is not required to lock them in any way.

Dan

----- Original Message -----
From: “Arlie Davis”
To: “Windows System Software Devs Interest List”
Sent: Friday, September 19, 2003 5:21 PM
Subject: [ntdev] Re: Peb is zero … even if PsLookupProcessByProcessId
returns ok …

> The PEB layout is fairly stable now, although technically you should
> never make assumptions about it – it’s strictly an OS internal
> structure, and you are tying your driver to an OS version, in a manner

> that will likely cause problems later, if the layout changes.
>
> Personally, I would go ahead and use the CommandLine stuff from the
> PEB. However, you’re doing it wrong. If you are writing this function

> to run in k-mode, you must first attach to the process (in order to
> map its VM address space), and you must use appropriate means to
> safely lock and probe user-mode pages. All of the PEB, including the
> CommandLine field and the string data that CommandLine.Buffer refers
> to, are stored in user-mode data pages, not in kernel-mode. Simply
> dereferencing a user-mode pointer in kernel-mode gets you an automatic

> F. There are lots of references on how to safely read user-mode data.
>
> If you do this, you MUST do some strict validation on the string
> length, etc., so that you stand a chance of being a well-behaved
> driver, if your driver gets loaded on a platform where CommandLine has

> changed or moved.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of System
> Sent: Friday, September 19, 2003 2:51 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Peb is zero … even if PsLookupProcessByProcessId

> returns ok …
>
>
> Dan
>
> the PID I am passing to this function is of a user mode process, that
> is why I expected a pointer to the user mode Ped to be returned.
>
> >>Also, you should treat an EPROCESS as a opaque data type and not
> >>reads
> directly from it.
>
> ok … but I really need the command line (long story) … any other
> suggestion … or tip on how I should proceed?
>
> thanks,
>
> Marco
> –
> System ( S_1_5_18 at hotmail.com )
>
> “Dan Partelly” wrote in message
> news:xxxxx@ntdev…
> >
> > A system thread is created in context of system process. Which dont
> > have
> any
> > kind of user mode control structures, hence not PEB. There are not
> > documented ways to do what you want from kernel mode. Also, you
> > should
> treat
> > an EPROCESS as a opaque data type and not reads directly from it.
> >
> > Dan
> >
> > ----- Original Message -----
> > From: “System”
> > Newsgroups: ntdev
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Friday, September 19, 2003 2:05 AM
> > Subject: [ntdev] Peb is zero … even if PsLookupProcessByProcessId
> > returns ok …
> >
> >
> > > Hi everybody,
> > >
> > > this is my second attempt at getting some help in extracting the
> > > command line parameters from a running process, this time with
> > > code.
>
> > > I have done
> > my
> > > homework but I am a new to systems programming … and I am stuck!
> > >
> > > The following code gets invoked from a thread
> > > (PsCreateSystemThread). PsLookupProcessByProcessId seems to
> > > succeed
>
> > > but the Peb is set to zero
> …
> > > any idea?
> > >
> > > ps: when PsLookupProcessByProcessId returns the value of “proc”
> > > is
> struct
> > > _EPROCESS * 0xffa32880
> > >
> > > void GetCommandLineFromPID (void p)
> > > {
> > > PIDex * const pid = (PIDex
)p; (PIDex is a simple struct )
> > >
> > > WCHAR* cmd;
> > > PEPROCESS proc = 0;
> > > PPEB peb = 0;
> > >
> > > pid->st = PsLookupProcessByProcessId ((PVOID)pid->pid, &proc);
> > >
> > > if (NT_SUCCESS(pid->st)) // st returns ok
> > > {
> > > peb = proc->Peb;
> > >
> > > if (peb != 0) // this is NOK – peb is always zero
> > > {
> > > cmd = (WCHAR *)peb->ProcessParameters->CommandLine.Buffer;
> > >
> > > if (cmd != 0)
> > > DbgPrint( “[%lxh] Command Line: %ws\n”, CT, cmd );
> > > }
> > >
> > > ObDereferenceObject(proc);
> > > }
> > >
> > > KeSetEvent(&pid->evt, 6, FALSE); PsTerminateSystemThread(0); }
> > >
> > > –
> > > Marco
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@rdsor.ro 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@sublinear.org 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@rdsor.ro 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@sublinear.org To
unsubscribe send a blank email to xxxxx@lists.osr.com