Moufiltr, ServiceCallback
in [Device Drivers]
|
Prev: Need 10us periodic timer in kernel mode
Next: UpdateDriverForPlugAndPlayDevices() return ERROR_FILE_NOT_FOUND on Vista x86
From: soviet_bloke on 11 Nov 2006 22:58 A brief look at mouclass sample shows the following block in MouseClassServiceCallback() if ((InputDataEnd == InputDataStart + 1) && (InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED)) { // // This is a notification packet that is not indicative of the user // being present. It is instead just a blank packet for the Raw // Input User Thread. // // We will pass it on, but we will not treat this as human input. // ; } else { // // Notify system that human input has occured // PoSetSystemState (ES_USER_PRESENT); } ntddmou. h defines MOUSE_ATTRIBUTES_CHANGED as 0x04. You have specified MOUSE_MOVE_RELATIVE flag, which is defined as 0 in ntddmou.h. Therefore, InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED will always be FALSE, which means that your "mouse event" will always be treated as an actual hardware event. Apparently, this is why you are crashing this time (a brief look at MouseClassServiceCallback() shows that my previous statement about spinlocks and IRQL is absolutely correct as well - it acquires a spinlock at DPC level) In general, you should not ask questions in the NG - instead, you should look at MouseClassServiceCallback() implementation in mouclass sample, so that you will discover everything yourself (AFAIK, kbdclass, mouclass and i8042prt are the provide the source to the *REAL* drivers, provided by the system) Anton Bassov BladeMaster wrote: > Using SendInput() has some problem with anti-virus program. > So I have to do it by driver. > > mouse port driver(i8042) simply send starting and end pointers of queue > filled with MOUSE_INPUT_DATA to moufiltr_ServiceCallback routine . > so I create a buffer in filter driver and copy the queue data from port > driver's one. > When I copy and inject data only in moufiltr_serviceCallback, > I works well. > But When I call the moufiltr_serviceCallBack from DispatchWrite routine(and > only injection), It crashes. > The following code is the part of my DispatchWrite() of moufiltr. > Any help much appreciated > thank you. > > ------------------------------------ > > InputData.Flags =MOUSE_MOVE_RELATIVE; > InputData.Buttons = 0; > // InputData.Buttons.ButtonData =0; > // InputData.Buttons.RawButtons = > InputData.LastX = *((ULONG*)buffer); > InputData.LastY = *((ULONG*)buffer+1); > > InputDataStart = &InputData; > InputDataEnd = InputDataStart+1; > > oldirq = KeRaiseIrqlToDpcLevel(); > > MouFilter_ServiceCallback( > DeviceObject, > InputDataStart, > InputDataEnd, > &InputDataConsumed > ); > KeLowerIrql(oldirq); > ------------------------------- > > > -- > Blade > > "soviet_bloke(a)hotmail.com" wrote: > > > > Actually MouFilter_ServiceCallback() is expected to be called by the port > > > driver. > > > > Indeed, it is supposed to get called by the port driver's DPC routine - > > this is why it is supposed to get called at DISPATCH_LEVEL. Therefore, > > its paramters are normally specified by the port driver, rather than > > your code . Are you sure your code passes > > correct parameters to it??? > > > > BTW, if I got it right, you just want to inject data into mouclass > > input queue upon your application's request, right? In other words, you > > are trying to simulate mouse activity. > > I don't know if it is appropriate solution in your situation, but you > > can do the above simply by calling SendInput() in the user mode, so > > that you don't even need a driver here > > > > Anton Bassov > > > > > > BladeMaster wrote: > > > Thank you for your kind answer. > > > > > > So I use KeRaiseIrqlToDpcLevel() before calling MouFilter_ServiceCallback() > > > in moufiltr_DIspathWrite(). > > > of course I also use KeLowerIrql() after call. > > > But it still crash. > > > > > > Actually MouFilter_ServiceCallback() is expected to be called by the port > > > driver. > > > But I'd like to call it from DispathWrite() of filter driver. > > > > > > Please give me any advice. > > > thank you. > > > > > > > > > KeRaiseIrqlToDpcLevel() > > > > > > -- > > > Blade > > > > > > "soviet_bloke(a)hotmail.com" wrote: > > > > > > > Hi mate > > > > > > > > > But when it call MouFilter_ServiceCallback() in IRP_MJ_WRITE hanlder, > > > > > PC is rebooted immediately. > > > > > > > > > > > > Have you noticed the following comment in > > > > MouFilter_ServiceCallback()??? > > > > > > > > // UpperConnectData must be called at DISPATCH > > > > > > > > Taking into consideration that MouFilter_ServiceCallback() does not do > > > > anything IRQL-related before calling UpperConnectData, it is easy to > > > > understand that it has to be called at DISPATCH_LEVEL. There are some > > > > certain things that cannot be done at low IRQL (for example, releasing > > > > a spinlock from DPC level) without screwing up the system. Therefore, > > > > once this comment has been added, it implies that UpperConnectData, > > > > apparently, does some operations that cannot be done at low IRQL. One > > > > does not even know the context in which it is supposed to get call to > > > > arrive to the above conclusion - looking at the souce alone is more > > > > than enough. > > > > > > > > However, IRP_MJ_WRITE that results from WriteFile() call gets processed > > > > at PASSIVE_LEVEL. Have you got any more questions why you crash when > > > > trying to call MouFilter_ServiceCallback() from IRP_MJ_WRITE > > > > handler???? > > > > > > > > Anton Bassov > > > > > > > > > > > > BladeMaster wrote: > > > > > I have been modified the DDK sample moufiltr driver to be accessed by user app. > > > > > user mode app can access to the control objcet with the symbolic link. > > > > > It also works well with WriteFile() - IRP_MJ_WRITE. > > > > > But when it call MouFilter_ServiceCallback() in IRP_MJ_WRITE hanlder, > > > > > PC is rebooted immediately. > > > > > > > > > > I'd like to create a mouse packet in the driver from the user mode app call. > > > > > What is wrong? What should I do? > > > > > > > > > > Thank you. > > > > > > > > > > -- > > > > > Blade > > > > > > > > > > > >
From: Doron Holan [MS] on 11 Nov 2006 23:33 yes, the WDK samples mouclass/kbdclass/i8042prt/mouser are all in box drivers and the src that build them is the same d -- Please do not send e-mail directly to this alias. this alias is for newsgroup purposes only. This posting is provided "AS IS" with no warranties, and confers no rights. <soviet_bloke(a)hotmail.com> wrote in message news:1163303936.783077.49490(a)k70g2000cwa.googlegroups.com... >A brief look at mouclass sample shows the following block in > MouseClassServiceCallback() > > if ((InputDataEnd == InputDataStart + 1) && > (InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED)) { > // > // This is a notification packet that is not indicative of the > user > // being present. It is instead just a blank packet for the > Raw > // Input User Thread. > // > // We will pass it on, but we will not treat this as human > input. > // > > ; > } else { > // > // Notify system that human input has occured > // > > PoSetSystemState (ES_USER_PRESENT); > } > > > ntddmou. h defines MOUSE_ATTRIBUTES_CHANGED as 0x04. You have specified > > MOUSE_MOVE_RELATIVE flag, which is defined as 0 in ntddmou.h. > Therefore, > InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED will always be FALSE, > which means that your "mouse event" will always be treated as an actual > hardware event. Apparently, this is why you are crashing this time (a > brief look at MouseClassServiceCallback() shows that my previous > statement about spinlocks and IRQL is absolutely correct as well - it > acquires a spinlock at DPC level) > > In general, you should not ask questions in the NG - instead, you > should look at MouseClassServiceCallback() implementation in mouclass > sample, so that you will discover everything yourself (AFAIK, kbdclass, > mouclass and i8042prt are the provide the source to the *REAL* drivers, > provided by the system) > > Anton Bassov > > > > BladeMaster wrote: >> Using SendInput() has some problem with anti-virus program. >> So I have to do it by driver. >> >> mouse port driver(i8042) simply send starting and end pointers of queue >> filled with MOUSE_INPUT_DATA to moufiltr_ServiceCallback routine . >> so I create a buffer in filter driver and copy the queue data from port >> driver's one. >> When I copy and inject data only in moufiltr_serviceCallback, >> I works well. >> But When I call the moufiltr_serviceCallBack from DispatchWrite >> routine(and >> only injection), It crashes. >> The following code is the part of my DispatchWrite() of moufiltr. >> Any help much appreciated >> thank you. >> >> ------------------------------------ >> >> InputData.Flags =MOUSE_MOVE_RELATIVE; >> InputData.Buttons = 0; >> // InputData.Buttons.ButtonData =0; >> // InputData.Buttons.RawButtons = >> InputData.LastX = *((ULONG*)buffer); >> InputData.LastY = *((ULONG*)buffer+1); >> >> InputDataStart = &InputData; >> InputDataEnd = InputDataStart+1; >> >> oldirq = KeRaiseIrqlToDpcLevel(); >> >> MouFilter_ServiceCallback( >> DeviceObject, >> InputDataStart, >> InputDataEnd, >> &InputDataConsumed >> ); >> KeLowerIrql(oldirq); >> ------------------------------- >> >> >> -- >> Blade >> >> "soviet_bloke(a)hotmail.com" wrote: >> >> > > Actually MouFilter_ServiceCallback() is expected to be called by the >> > > port >> > > driver. >> > >> > Indeed, it is supposed to get called by the port driver's DPC routine - >> > this is why it is supposed to get called at DISPATCH_LEVEL. Therefore, >> > its paramters are normally specified by the port driver, rather than >> > your code . Are you sure your code passes >> > correct parameters to it??? >> > >> > BTW, if I got it right, you just want to inject data into mouclass >> > input queue upon your application's request, right? In other words, you >> > are trying to simulate mouse activity. >> > I don't know if it is appropriate solution in your situation, but you >> > can do the above simply by calling SendInput() in the user mode, so >> > that you don't even need a driver here >> > >> > Anton Bassov >> > >> > >> > BladeMaster wrote: >> > > Thank you for your kind answer. >> > > >> > > So I use KeRaiseIrqlToDpcLevel() before calling >> > > MouFilter_ServiceCallback() >> > > in moufiltr_DIspathWrite(). >> > > of course I also use KeLowerIrql() after call. >> > > But it still crash. >> > > >> > > Actually MouFilter_ServiceCallback() is expected to be called by the >> > > port >> > > driver. >> > > But I'd like to call it from DispathWrite() of filter driver. >> > > >> > > Please give me any advice. >> > > thank you. >> > > >> > > >> > > KeRaiseIrqlToDpcLevel() >> > > >> > > -- >> > > Blade >> > > >> > > "soviet_bloke(a)hotmail.com" wrote: >> > > >> > > > Hi mate >> > > > >> > > > > But when it call MouFilter_ServiceCallback() in IRP_MJ_WRITE >> > > > > hanlder, >> > > > > PC is rebooted immediately. >> > > > >> > > > >> > > > Have you noticed the following comment in >> > > > MouFilter_ServiceCallback()??? >> > > > >> > > > // UpperConnectData must be called at DISPATCH >> > > > >> > > > Taking into consideration that MouFilter_ServiceCallback() does not >> > > > do >> > > > anything IRQL-related before calling UpperConnectData, it is easy >> > > > to >> > > > understand that it has to be called at DISPATCH_LEVEL. There are >> > > > some >> > > > certain things that cannot be done at low IRQL (for example, >> > > > releasing >> > > > a spinlock from DPC level) without screwing up the system. >> > > > Therefore, >> > > > once this comment has been added, it implies that UpperConnectData, >> > > > apparently, does some operations that cannot be done at low IRQL. >> > > > One >> > > > does not even know the context in which it is supposed to get call >> > > > to >> > > > arrive to the above conclusion - looking at the souce alone is more >> > > > than enough. >> > > > >> > > > However, IRP_MJ_WRITE that results from WriteFile() call gets >> > > > processed >> > > > at PASSIVE_LEVEL. Have you got any more questions why you crash >> > > > when >> > > > trying to call MouFilter_ServiceCallback() from IRP_MJ_WRITE >> > > > handler???? >> > > > >> > > >
From: Doron Holan [MS] on 11 Nov 2006 23:33 how about posting a callstack and the output of !analyze -v? debugging in the dark is a bit hard sometimes... d -- Please do not send e-mail directly to this alias. this alias is for newsgroup purposes only. This posting is provided "AS IS" with no warranties, and confers no rights. <soviet_bloke(a)hotmail.com> wrote in message news:1163303936.783077.49490(a)k70g2000cwa.googlegroups.com... >A brief look at mouclass sample shows the following block in > MouseClassServiceCallback() > > if ((InputDataEnd == InputDataStart + 1) && > (InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED)) { > // > // This is a notification packet that is not indicative of the > user > // being present. It is instead just a blank packet for the > Raw > // Input User Thread. > // > // We will pass it on, but we will not treat this as human > input. > // > > ; > } else { > // > // Notify system that human input has occured > // > > PoSetSystemState (ES_USER_PRESENT); > } > > > ntddmou. h defines MOUSE_ATTRIBUTES_CHANGED as 0x04. You have specified > > MOUSE_MOVE_RELATIVE flag, which is defined as 0 in ntddmou.h. > Therefore, > InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED will always be FALSE, > which means that your "mouse event" will always be treated as an actual > hardware event. Apparently, this is why you are crashing this time (a > brief look at MouseClassServiceCallback() shows that my previous > statement about spinlocks and IRQL is absolutely correct as well - it > acquires a spinlock at DPC level) > > In general, you should not ask questions in the NG - instead, you > should look at MouseClassServiceCallback() implementation in mouclass > sample, so that you will discover everything yourself (AFAIK, kbdclass, > mouclass and i8042prt are the provide the source to the *REAL* drivers, > provided by the system) > > Anton Bassov > > > > BladeMaster wrote: >> Using SendInput() has some problem with anti-virus program. >> So I have to do it by driver. >> >> mouse port driver(i8042) simply send starting and end pointers of queue >> filled with MOUSE_INPUT_DATA to moufiltr_ServiceCallback routine . >> so I create a buffer in filter driver and copy the queue data from port >> driver's one. >> When I copy and inject data only in moufiltr_serviceCallback, >> I works well. >> But When I call the moufiltr_serviceCallBack from DispatchWrite >> routine(and >> only injection), It crashes. >> The following code is the part of my DispatchWrite() of moufiltr. >> Any help much appreciated >> thank you. >> >> ------------------------------------ >> >> InputData.Flags =MOUSE_MOVE_RELATIVE; >> InputData.Buttons = 0; >> // InputData.Buttons.ButtonData =0; >> // InputData.Buttons.RawButtons = >> InputData.LastX = *((ULONG*)buffer); >> InputData.LastY = *((ULONG*)buffer+1); >> >> InputDataStart = &InputData; >> InputDataEnd = InputDataStart+1; >> >> oldirq = KeRaiseIrqlToDpcLevel(); >> >> MouFilter_ServiceCallback( >> DeviceObject, >> InputDataStart, >> InputDataEnd, >> &InputDataConsumed >> ); >> KeLowerIrql(oldirq); >> ------------------------------- >> >> >> -- >> Blade >> >> "soviet_bloke(a)hotmail.com" wrote: >> >> > > Actually MouFilter_ServiceCallback() is expected to be called by the >> > > port >> > > driver. >> > >> > Indeed, it is supposed to get called by the port driver's DPC routine - >> > this is why it is supposed to get called at DISPATCH_LEVEL. Therefore, >> > its paramters are normally specified by the port driver, rather than >> > your code . Are you sure your code passes >> > correct parameters to it??? >> > >> > BTW, if I got it right, you just want to inject data into mouclass >> > input queue upon your application's request, right? In other words, you >> > are trying to simulate mouse activity. >> > I don't know if it is appropriate solution in your situation, but you >> > can do the above simply by calling SendInput() in the user mode, so >> > that you don't even need a driver here >> > >> > Anton Bassov >> > >> > >> > BladeMaster wrote: >> > > Thank you for your kind answer. >> > > >> > > So I use KeRaiseIrqlToDpcLevel() before calling >> > > MouFilter_ServiceCallback() >> > > in moufiltr_DIspathWrite(). >> > > of course I also use KeLowerIrql() after call. >> > > But it still crash. >> > > >> > > Actually MouFilter_ServiceCallback() is expected to be called by the >> > > port >> > > driver. >> > > But I'd like to call it from DispathWrite() of filter driver. >> > > >> > > Please give me any advice. >> > > thank you. >> > > >> > > >> > > KeRaiseIrqlToDpcLevel() >> > > >> > > -- >> > > Blade >> > > >> > > "soviet_bloke(a)hotmail.com" wrote: >> > > >> > > > Hi mate >> > > > >> > > > > But when it call MouFilter_ServiceCallback() in IRP_MJ_WRITE >> > > > > hanlder, >> > > > > PC is rebooted immediately. >> > > > >> > > > >> > > > Have you noticed the following comment in >> > > > MouFilter_ServiceCallback()??? >> > > > >> > > > // UpperConnectData must be called at DISPATCH >> > > > >> > > > Taking into consideration that MouFilter_ServiceCallback() does not >> > > > do >> > > > anything IRQL-related before calling UpperConnectData, it is easy >> > > > to >> > > > understand that it has to be called at DISPATCH_LEVEL. There are >> > > > some >> > > > certain things that cannot be done at low IRQL (for example, >> > > > releasing >> > > > a spinlock from DPC level) without screwing up the system. >> > > > Therefore, >> > > > once this comment has been added, it implies that UpperConnectData, >> > > > apparently, does some operations that cannot be done at low IRQL. >> > > > One >> > > > does not even know the context in which it is supposed to get call >> > > > to >> > > > arrive to the above conclusion - looking at the souce alone is more >> > > > than enough. >> > > > >> > > > However, IRP_MJ_WRITE that results from WriteFile() call gets >> > > > processed >> > > > at PASSIVE_LEVEL. Have you got any more questions why you crash >> > > > when >> > > > trying to call MouFilter_ServiceCallback() from IRP_MJ_WRITE >> > > > handler???? >> > > > >> > > > Anton
From: soviet_bloke on 11 Nov 2006 23:57 Doron, > how about posting a callstack and the output of !analyze -v? Apparently, this is going to be the OP's next step - up to this point we were speaking about the problems that can be immediately identified simply by looking at the source...... Anton Bassov Doron Holan [MS] wrote: > how about posting a callstack and the output of !analyze -v? debugging in > the dark is a bit hard sometimes... > > d > > -- > Please do not send e-mail directly to this alias. this alias is for > newsgroup purposes only. > This posting is provided "AS IS" with no warranties, and confers no rights. > > > <soviet_bloke(a)hotmail.com> wrote in message > news:1163303936.783077.49490(a)k70g2000cwa.googlegroups.com... > >A brief look at mouclass sample shows the following block in > > MouseClassServiceCallback() > > > > if ((InputDataEnd == InputDataStart + 1) && > > (InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED)) { > > // > > // This is a notification packet that is not indicative of the > > user > > // being present. It is instead just a blank packet for the > > Raw > > // Input User Thread. > > // > > // We will pass it on, but we will not treat this as human > > input. > > // > > > > ; > > } else { > > // > > // Notify system that human input has occured > > // > > > > PoSetSystemState (ES_USER_PRESENT); > > } > > > > > > ntddmou. h defines MOUSE_ATTRIBUTES_CHANGED as 0x04. You have specified > > > > MOUSE_MOVE_RELATIVE flag, which is defined as 0 in ntddmou.h. > > Therefore, > > InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED will always be FALSE, > > which means that your "mouse event" will always be treated as an actual > > hardware event. Apparently, this is why you are crashing this time (a > > brief look at MouseClassServiceCallback() shows that my previous > > statement about spinlocks and IRQL is absolutely correct as well - it > > acquires a spinlock at DPC level) > > > > In general, you should not ask questions in the NG - instead, you > > should look at MouseClassServiceCallback() implementation in mouclass > > sample, so that you will discover everything yourself (AFAIK, kbdclass, > > mouclass and i8042prt are the provide the source to the *REAL* drivers, > > provided by the system) > > > > Anton Bassov > > > > > > > > BladeMaster wrote: > >> Using SendInput() has some problem with anti-virus program. > >> So I have to do it by driver. > >> > >> mouse port driver(i8042) simply send starting and end pointers of queue > >> filled with MOUSE_INPUT_DATA to moufiltr_ServiceCallback routine . > >> so I create a buffer in filter driver and copy the queue data from port > >> driver's one. > >> When I copy and inject data only in moufiltr_serviceCallback, > >> I works well. > >> But When I call the moufiltr_serviceCallBack from DispatchWrite > >> routine(and > >> only injection), It crashes. > >> The following code is the part of my DispatchWrite() of moufiltr. > >> Any help much appreciated > >> thank you. > >> > >> ------------------------------------ > >> > >> InputData.Flags =MOUSE_MOVE_RELATIVE; > >> InputData.Buttons = 0; > >> // InputData.Buttons.ButtonData =0; > >> // InputData.Buttons.RawButtons = > >> InputData.LastX = *((ULONG*)buffer); > >> InputData.LastY = *((ULONG*)buffer+1); > >> > >> InputDataStart = &InputData; > >> InputDataEnd = InputDataStart+1; > >> > >> oldirq = KeRaiseIrqlToDpcLevel(); > >> > >> MouFilter_ServiceCallback( > >> DeviceObject, > >> InputDataStart, > >> InputDataEnd, > >> &InputDataConsumed > >> ); > >> KeLowerIrql(oldirq); > >> ------------------------------- > >> > >> > >> -- > >> Blade > >> > >> "soviet_bloke(a)hotmail.com" wrote: > >> > >> > > Actually MouFilter_ServiceCallback() is expected to be called by the > >> > > port > >> > > driver. > >> > > >> > Indeed, it is supposed to get called by the port driver's DPC routine - > >> > this is why it is supposed to get called at DISPATCH_LEVEL. Therefore, > >> > its paramters are normally specified by the port driver, rather than > >> > your code . Are you sure your code passes > >> > correct parameters to it??? > >> > > >> > BTW, if I got it right, you just want to inject data into mouclass > >> > input queue upon your application's request, right? In other words, you > >> > are trying to simulate mouse activity. > >> > I don't know if it is appropriate solution in your situation, but you > >> > can do the above simply by calling SendInput() in the user mode, so > >> > that you don't even need a driver here > >> > > >> > Anton Bassov > >> > > >> > > >> > BladeMaster wrote: > >> > > Thank you for your kind answer. > >> > > > >> > > So I use KeRaiseIrqlToDpcLevel() before calling > >> > > MouFilter_ServiceCallback() > >> > > in moufiltr_DIspathWrite(). > >> > > of course I also use KeLowerIrql() after call. > >> > > But it still crash. > >> > > > >> > > Actually MouFilter_ServiceCallback() is expected to be called by the > >> > > port > >> > > driver. > >> > > But I'd like to call it from DispathWrite() of filter driver. > >> > > > >> > > Please give me any advice. > >> > > thank you. > >> > > > >> > > > >> > > KeRaiseIrqlToDpcLevel() > >> > > > >> > > -- > >> > > Blade > >> > > > >> > > "soviet_bloke(a)hotmail.com" wrote: > >> > > > >> > > > Hi mate > >> > > > > >> > > > > But when it call MouFilter_ServiceCallback() in IRP_MJ_WRITE > >> > > > > hanlder, > >> > > > > PC is rebooted immediately. > >> > > > > >> > > > > >> > > > Have you noticed the following comment in > >> > > > MouFilter_ServiceCallback()??? > >> > > > > >> > > > // UpperConnectData must be called at DISPATCH > >> > > > > >> > > > Taking into consideration that MouFilter_ServiceCallback() does not > >> > > > do > >> > > > anything IRQL-related before calling UpperConnectData, it is easy > >> > > > to > >> > > > understand that it has to be called at DISPATCH_LEVEL. There are > >> > > > some > >> > > > certain things that cannot be done at low IRQL (for example, > >> > > > releasing > >> > > > a spinlock from DPC level) without screwing up the system. > >> > > > Therefore, > >> > > > once this comment has been ad
From: BladeMaster on 12 Nov 2006 03:50
Thank you. I am a novice. Frankly speaking, I couldn't set up a kernel debugger.. --; (My target PC has no COM port, so I couldn't connect NULL-modem cable) I already looked at mouclass and i8042 samples many times but I couldn't find solution, so I posted questions. Anyway your replies are very helpful. (But I cannot understand what's the problem if my mouse event were treated as an actual hardware event) And I'll have to study harder and try to do it by myself ^^ Thank you again. -- Blade "soviet_bloke(a)hotmail.com" wrote: > Doron, > > > how about posting a callstack and the output of !analyze -v? > > Apparently, this is going to be the OP's next step - up to this point > we were speaking about > the problems that can be immediately identified simply by looking at > the source...... > > Anton Bassov > > > Doron Holan [MS] wrote: > > how about posting a callstack and the output of !analyze -v? debugging in > > the dark is a bit hard sometimes... > > > > d > > > > -- > > Please do not send e-mail directly to this alias. this alias is for > > newsgroup purposes only. > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > > > > <soviet_bloke(a)hotmail.com> wrote in message > > news:1163303936.783077.49490(a)k70g2000cwa.googlegroups.com... > > >A brief look at mouclass sample shows the following block in > > > MouseClassServiceCallback() > > > > > > if ((InputDataEnd == InputDataStart + 1) && > > > (InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED)) { > > > // > > > // This is a notification packet that is not indicative of the > > > user > > > // being present. It is instead just a blank packet for the > > > Raw > > > // Input User Thread. > > > // > > > // We will pass it on, but we will not treat this as human > > > input. > > > // > > > > > > ; > > > } else { > > > // > > > // Notify system that human input has occured > > > // > > > > > > PoSetSystemState (ES_USER_PRESENT); > > > } > > > > > > > > > ntddmou. h defines MOUSE_ATTRIBUTES_CHANGED as 0x04. You have specified > > > > > > MOUSE_MOVE_RELATIVE flag, which is defined as 0 in ntddmou.h. > > > Therefore, > > > InputDataStart->Flags & MOUSE_ATTRIBUTES_CHANGED will always be FALSE, > > > which means that your "mouse event" will always be treated as an actual > > > hardware event. Apparently, this is why you are crashing this time (a > > > brief look at MouseClassServiceCallback() shows that my previous > > > statement about spinlocks and IRQL is absolutely correct as well - it > > > acquires a spinlock at DPC level) > > > > > > In general, you should not ask questions in the NG - instead, you > > > should look at MouseClassServiceCallback() implementation in mouclass > > > sample, so that you will discover everything yourself (AFAIK, kbdclass, > > > mouclass and i8042prt are the provide the source to the *REAL* drivers, > > > provided by the system) > > > > > > Anton Bassov > > > > > > > > > > > > BladeMaster wrote: > > >> Using SendInput() has some problem with anti-virus program. > > >> So I have to do it by driver. > > >> > > >> mouse port driver(i8042) simply send starting and end pointers of queue > > >> filled with MOUSE_INPUT_DATA to moufiltr_ServiceCallback routine . > > >> so I create a buffer in filter driver and copy the queue data from port > > >> driver's one. > > >> When I copy and inject data only in moufiltr_serviceCallback, > > >> I works well. > > >> But When I call the moufiltr_serviceCallBack from DispatchWrite > > >> routine(and > > >> only injection), It crashes. > > >> The following code is the part of my DispatchWrite() of moufiltr. > > >> Any help much appreciated > > >> thank you. > > >> > > >> ------------------------------------ > > >> > > >> InputData.Flags =MOUSE_MOVE_RELATIVE; > > >> InputData.Buttons = 0; > > >> // InputData.Buttons.ButtonData =0; > > >> // InputData.Buttons.RawButtons = > > >> InputData.LastX = *((ULONG*)buffer); > > >> InputData.LastY = *((ULONG*)buffer+1); > > >> > > >> InputDataStart = &InputData; > > >> InputDataEnd = InputDataStart+1; > > >> > > >> oldirq = KeRaiseIrqlToDpcLevel(); > > >> > > >> MouFilter_ServiceCallback( > > >> DeviceObject, > > >> InputDataStart, > > >> InputDataEnd, > > >> &InputDataConsumed > > >> ); > > >> KeLowerIrql(oldirq); > > >> ------------------------------- > > >> > > >> > > >> -- > > >> Blade > > >> > > >> "soviet_bloke(a)hotmail.com" wrote: > > >> > > >> > > Actually MouFilter_ServiceCallback() is expected to be called by the > > >> > > port > > >> > > driver. > > >> > > > >> > Indeed, it is supposed to get called by the port driver's DPC routine - > > >> > this is why it is supposed to get called at DISPATCH_LEVEL. Therefore, > > >> > its paramters are normally specified by the port driver, rather than > > >> > your code . Are you sure your code passes > > >> > correct parameters to it??? > > >> > > > >> > BTW, if I got it right, you just want to inject data into mouclass > > >> > input queue upon your application's request, right? In other words, you > > >> > are trying to simulate mouse activity. > > >> > I don't know if it is appropriate solution in your situation, but you > > >> > can do the above simply by calling SendInput() in the user mode, so > > >> > that you don't even need a driver here > > >> > > > >> > Anton Bassov > > >> > > > >> > > > >> > BladeMaster wrote: > > >> > > Thank you for your kind answer. > > >> > > > > >> > > So I use KeRaiseIrqlToDpcLevel() before calling > > >> > > MouFilter_ServiceCallback() > > >> > > in moufiltr_DIspathWrite(). > > >> > > of course I also use KeLowerIrql() after call. > > >> > > But it still crash. > > >> > > > > >> > > Actually MouFilter_ServiceCallback() is expected to be called by the > > >> > > port > > >> > > driver. > > >> > > But I'd like to call it from DispathWrite() of filter driver. > > >> > > > > >> > > Please give me any advice. > > >> > > thank you. > > >> > > > > >> > > > > >> > > KeRaiseIrqlToDpcLevel() > > >> > > > > >> > > -- > > >> > > Blade > > >> > > > > >> > > "soviet_bloke(a)hotmail.com" wrote: > > >> |