There are several reasons why you could be losing packets.
You are mentioning heavy traffic. Are you sure that your miniport
DPCforISR has seen them.
One possibility could be that you running out of the Packet Descritor
Queue. Since whatever you are doing in the DPC or wherever
is taking a long time. Having a circular buffer might
not necessarily solve your problem.
If you card supports drop count try querying it.
>>From: Yuanhui Zhao [mailto:xxxxx@nexland.com]
>>Sent: Thursday, August 22, 2002 11:15 AM
>>To: NT Developers Interest List
>>Subject: [ntdev] Re: Passing event notification from driver to
>>application
>>Peter and Heldai,
>>Thanks for your help! Finally I worked out. The problem is I didn’t
>>initialize the event in the driver (it’s initialized in the application
and
>>sent a handler to the driver). In my driver code, I added a NULL
checking
>>statement before setting the event. Now it works fine.
>>
>>However, another question arises. For heavy traffic, I lose packets.
>>Basically I copy the packets to Irp.AssociatedIrp.SystemBuffer, notify
the
>>application that new packet comes in, application use DeviceIoControl
to
>>read the buffer. Now my question is: can I make the SystemBuffer a
circular
>>buffer in order increase the capacity of the buffer to process more
packets?
>>Any idea is appreciated.
>>
>>Yuanhui
----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Thursday, August 22, 2002 12:17 PM
Subject: [ntdev] Re: Passing event notification from driver to application
> “Heldai” wrote in message news:xxxxx@ntdev…
> >
> > In KernelMode try use it :
> >
> > ObReferenceObjectByHandle(h,
> > 0,
> > NULL,
> > KernelMode,
> > (PVOID *)(&gUserEvent),
> > NULL) ;
> >
> > Do you are referencing your handle in kernel mode.
> >
>
> Good heavens, please don’t do it that way. This opens up at least one
ugly
> security hole.
>
> First of all, suppose the handle the user passes in isn’t a handle to an
> event. And then, suppose the user doesn’t have access to the handle.
>
> The proper way to reference a handle to an event passed from user-mode to
a
> driver is as follows:
>
> Status = ObReferenceObjectByHandle(
> SharedEventHandle,
> EVENT_ALL_ACCESS,
> *ExEventObjectType, // Check the
> object type… fail if not an event
> UserMode, // Check
> for required access in USER mode
> &SharedEvent,
> NULL);
>
> Please, NEVER omit the object type being referenced. It’s just ASKING for
> trouble.
>
> Also, note that this function call must be made in the context of the
> process that created the event. That is, the handle is process-specific.
> If all your function calls are working, Mr. Zhao, but you’re not seeing
the
> appropriate event set, then it is likely that you’re doing the ObRef… in
> the wrong context. And, note that in many cases (though obviously not all)
> specifying the object type will actually help you catch this problem.
>
> To the larger issue raised by Mr. Zhao:
>
> 1)
> if (ControlCode == IOCTL_PIM_SET_EVENT)
> {
>
> h = *((PHANDLE)
irpStack->Parameters.DeviceIoControl.Type3InputBuffer);
> Status = ObReferenceObjectByHandle(
> h,
> GENERIC_ALL,
> NULL,
> UserMode,
> (PVOID)&gUserEvent,
> (POBJECT_HANDLE_INFORMATION)NULL
> );
> if(Status != STATUS_SUCCESS)
> {
> DbgPrint(“ObReferenceObjectByHandle failed! status = %x\n”, Status);
> break;
> }
> DbgPrint(“Referenct object sussfully!\n”);
>
> Assuming the ObReference… is corrected, I sure hope the above is
> “pseudo-code”… please tell me that you’re checking that the length of
the
> buffer is at least 4 bytes, and that the pointer is non-NULL, before
> dereferencing it as shown above.
>
> 2)
> For all the reasons discussed above, and more, I really struggle with the
> entire concept of sharing events by having a user-mode app send a handle
> into a driver. Why not share an event by name? Have the user-app create
> the named event, then just open the damn thing:
>
> //
> // When you create a named event in user mode \BaseNamedObjects<br>is
> // prepended to the name specified in the call to CreateEvent
> //
> RtlInitUnicodeString(&EventName,
> L"\BaseNamedObjects\SharedEvent");
>
> //
> // Get a pointer to a KEVENT object that is associated with this
> // named event
> //
> SharedEvent = IoCreateNotificationEvent(&EventName,
> &SharedEventHandle);
>
> Doesn’t this strike everyone as much more sane and secure?
>
> 3)
> Mr. Zhao, you don’t give us any information as to HOW what you’re doing
> fails. Perhaps you can describe the behavior you’re seeing?
>
> 4)
> We’ve written (well, actually, OSR’s Scott Noone did the work) an article
> and a sample driver for the next issue of The NT Insider to try to fully
> address this issue about sharing events between user apps and drivers. It
> seems to be an increasingly common question, and there seems to be a lot
of
> marginally correct information out there (feel free to suggest your
> favorite hot-button on this topic for inclusion… reply direct, please,
not
> to the list).
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nexland.com
> To unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to %%email.unsub%%
is that prior to .NET, IoCreateNotificationEvent and