9DAe;MEc;c;Of;Kc;A=He;Jf;IJf;FFf;IJEe;C06d;c;f;a;
“f” wrote in message news:xxxxx@ntdev…
> 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…
>>
>>–
>>Mats
>>
>>
>>xxxxx@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=256
>>
>>You 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
> --ÎÞÓǶþ¶þ×å¡¢×ãÇò´ó¸»ÎÌ…¾¡ÔÚÒÚÓʶÌÐÅ
>