Now I find out where is the troublesome code :
In DriverEntry:
for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++){
DriverObject->MajorFunction[i] = Flt_Dispatch;
}
Following it ,IoCreateDevice was called to create a CDO (Control device
Object) for communication with user-mode program.
But they can collaborate well.
If I earse the IoCreateDevice and keep the for{…} ,the Driver can
work;
If I earse the for{…} and keep the IoCreateDevice ,the Driver can work
too.
Who know what is the matter?
As far as I’m aware, Display isn’t special in it’s handling of IRP’s, but
of course, most of the display driver activity doesn’t actually happen
through IRP’s, but through variour calls directly to the driver which are
exported by the display driver. I’m not sure how this works for filter
drivers, but I expect that the filter driver will call the Display driver
proper for the call-backs.I’d suggest you get WinDBG or SoftICE hooked up to the machine you’re
trying to load the filter on, and start debugging. It could be just about
ANYTHING that causes it to go wrong…–
Matsxxxxx@lists.osr.com wrote on 11/25/2004 09:31:10 AM:
> Hi,
> I have just written a DISPLAY Class upperfilter driver.
> But soon after system boot,BOSD occured!
> The upperfilter driver just passthru each IRP , and never do anything.
> Maybe DISPLAY class filter driver is something special?
>
> p.f
>
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@eyou.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–http://www.eyou.com
–Îȶ¨¿É¿¿µÄµç×ÓÐÅÏä ÓïÒôÓʼþ Òƶ¯ÊéÇ© ÈÕÀú·þÎñ ÍøÂç´æ´¢…ÒÚÓÊδ¾¡
–http://vip.eyou.com
–¿ì¿ìµÇ¼ÒÚÓÊVIPÐÅÏä ×¢²áÄúÖÐÒâµÄÓû§Ãû
–http://sms.eyou.com
–ÎÞÓǶþ¶þ×å¡¢×ãÇò´ó¸»ÎÌ…¾¡ÔÚÒÚÓʶÌÐÅ