Hope this isn’t duplicate
If I remember right - for every TDI client call,
I created my own completion function. For the
TDI completion - used the same completion function
for all TDI requests.
For each request, I had defined a structure which contained
various information including the type of command and my
specific completion function into PsCreateSystemThread.
In the thread routine, I newed an Event and stored its
address along with the address into a structure which
got stashed into IRP which I created here. Then I issued
the command and waited on the event.
The event would always complete in the common TDI completion
routine (always at IRQ > PASSIVE) Here, depending on the result,
I would Signal the event (stashed in the IRP) and return.
Control would return to my Thread routine (IRQL PASSIVE) - where I would
call my specific completion function. When that completed -
I completed the request and threw away the IRP & close thread.
One gotcha - sometimes the Thread routine would complete
before control returned from the PsCreateSystemThread and
handle would be null. Had to check result after create thread
rather then handle
If I remember right - this is how it worked for me.
RQ
----- Original Message -----
From: “Alon Dashut”
To: “NT Developers Interest List”
Sent: Thursday, July 26, 2001 1:48 PM
Subject: [ntdev] RE: KeWaitForSingleObjects problem (TDI related).
> I’m not sure… How can I be positive that it’s not pageable?
> As a matter of fact: I have done thing to make it non-pageable.
> Do I have to wrap my code with a certain macro?
>
> I’ve tried creating an internal system thread using:
> ‘PsCreateSystemThread()’ and then I let this thread run the connection
code
> -> hoping that the ‘KernelMode’ option in function ‘KeWaitForSingleObject’
> had something to do with it. But I the system crashed at exactly the same
> point…
>
> What I further understand is, after I call ‘KeWaitForSingleObject’, a few
> (very few) seconds pass and only then does the system crash, meaning, that
> TDI DID try to connect to the remote, and when it wanted to “say” that
it
> has/hasn’t connected -> it DIDN’T manage to call the callback routine
> (‘makeDriverCallComplete()’) but rather crashed. Note that a pervious call
> to create the Connection object (before actually connecting), DOES call
the
> callback routine and everything works fine.
>
> Waiting for your help, Dashut Alon.
>
> -----Original Message-----
> From: Parton, Charles W. [mailto:xxxxx@xetron.com]
> Sent: Thursday, July 26, 2001 7:00 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: KeWaitForSingleObjects problem (TDI related).
>
>
> I don’t see anything wrong with the code; your driver isn’t pagable, is
it?
>
> -----Original Message-----
> From: Alon Dashut [mailto:xxxxx@AppStream.co.il]
> Sent: Thursday, July 26, 2001 11:23 AM
> To: NT Developers Interest List
> Subject: [ntdev] KeWaitForSingleObjects problem (TDI related).
>
>
> Hi.
> I’m trying to connect to a remote Server using TDI with the call to
> ‘IoCallDriver()’.
> Before calling this method, I have done all other requirements (Address
> object, Connection object, associated them).
> But what happens here, is that the system crashes when calling
> ‘KeWaitForSingleObjects’.
> ‘KeWaitForSingleObjects’ is called only when status is pending -> this is
> the case only when I try to connect (what I mean is, that I previously
> called this method when creating the Connection object before actually
> connecting).
> I did check that IRQL is PASSIVE_LEVEL before calling
> ‘KeWaitForSingleObjects’.
> I use Numega’s SoftIce, so I know exactly where the system crashes
> (‘KeWaitForSingleObjects’).
>
> Here is my code, and following that is the code of the callback routine
> required by ‘IoCallDriver()’.
>
>
> NTSTATUS makeDriverCall(IN PDEVICE_OBJECT pDeviceObject, IN PIRP pIrp)
> {
> NTSTATUS status;
> KEVENT event;
>
> DBGASSERT( KeGetCurrentIrql() == PASSIVE_LEVEL );
>
> KeInitializeEvent (&event, NotificationEvent, FALSE);
>
> IoSetCompletionRoutine(
> pIrp, // The IRP
> makeDriverCallComplete, // The completion routine
> &event, // The completion context
> TRUE, // Invoke On Success
> TRUE, // Invoke On Error
> TRUE // Invoke On Cancel
> );
>
> // Submit the request
> status = IoCallDriver(pDeviceObject, pIrp );
>
> if (status == STATUS_PENDING)
> {
> DBGASSERT( KeGetCurrentIrql() == PASSIVE_LEVEL );
>
> status = KeWaitForSingleObject(
> &event, // Object to wait on.
> Executive, // Reason for waiting
> KernelMode, // Processor mode
> FALSE, // Alertable
> NULL // Timeout
> );
> }
> return (status);
> }
>
> The completion routine:
>
> NTSTATUS makeDriverCallComplete(IN PDEVICE_OBJECT deviceObject,
> IN PIRP irp,
> IN PVOID context )
> {
> if (context != NULL)
> KeSetEvent((PKEVENT )context, 0, FALSE);
>
> return (STATUS_MORE_PROCESSING_REQUIRED);
> }
> —
> You are currently subscribed to ntdev as: xxxxx@xetron.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@AppStream.co.il
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
>
******************************************************
> The contents of this email and any attachments are confidential.
> It is intended for the named recipient(s) only.
> If you have received this email in error please notify the system manager
or the
> sender immediately and do not disclose the contents to any one or make
copies.
>
> Our security system’s scanned this email for viruses, vandals and
malicious content
>
>
******************************************************
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@silcom.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com