|
I took a quick look again here in a little more detail and here's what I think is happening.
The keyboard generates the keydown event and it's most likely passed and filtered by the WH_KEYBOARD_LL hooks first. Eventually, it makes it way as a WM_KEYDOWN message into the active window. In the case where I saw it in CSRSS's message queue, was since I had the command window debugger active.
So, then the ScanQueue is called and there's a call to get the next message. Then, it's checked if it's a keydown. If it is, it then checks specific scan codes and performs certain system actions.
kd> r
eax=e1ba81e8 ebx=e1cb0a48 ecx=00000001 edx=00005d6e esi=00000000 edi=00000001
eip=a0025769 esp=f766fbac ebp=f766fc8c iopl=3 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003246
win32k!xxxScanSysQueue+0xa2:
a0025769 e80d0f0000 call win32k!xxxGetNextSysMsg (a002667b)
kd> p;r
...
kd>
eax=00000000 ebx=e1cb0a48 ecx=f766fc20 edx=00000000 esi=00000000 edi=00000001
eip=a00257bf esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei ng nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003283
win32k!xxxScanSysQueue+0x10c:
a00257bf 8b4dac mov ecx,[ebp-0x54] ss:0010:f766fc38=00000100
kd>
eax=00000000 ebx=e1cb0a48 ecx=00000100 edx=00000000 esi=00000000 edi=00000001
eip=a00257c2 esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei ng nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003283
win32k!xxxScanSysQueue+0x10f:
a00257c2 6a23 push 0x23
kd>
eax=00000000 ebx=e1cb0a48 ecx=00000100 edx=00000000 esi=00000000 edi=00000001
eip=a00257c4 esp=f766fbb4 ebp=f766fc8c iopl=3 nv up ei ng nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003283
win32k!xxxScanSysQueue+0x111:
a00257c4 5a pop edx
kd>
eax=00000000 ebx=e1cb0a48 ecx=00000100 edx=00000023 esi=00000000 edi=00000001
eip=a00257c5 esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei ng nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003283
win32k!xxxScanSysQueue+0x112:
a00257c5 894d08 mov [ebp+0x8],ecx ss:0010:f766fc94=e1cb0a48
kd>
eax=00000000 ebx=e1cb0a48 ecx=00000100 edx=00000023 esi=00000000 edi=00000001
eip=a00257c8 esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei ng nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003283
win32k!xxxScanSysQueue+0x115:
a00257c8 2bca sub ecx,edx
kd>
eax=00000000 ebx=e1cb0a48 ecx=000000dd edx=00000023 esi=00000000 edi=00000001
eip=a00257ca esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003216
win32k!xxxScanSysQueue+0x117:
a00257ca 0f841b0c0000 je win32k!xxxScanSysQueue+0xe3f (a00263eb) [br=0]
kd>
eax=00000000 ebx=e1cb0a48 ecx=000000dd edx=00000023 esi=00000000 edi=00000001
eip=a00257d0 esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003216
win32k!xxxScanSysQueue+0x11d:
a00257d0 81e9dd000000 sub ecx,0xdd
kd>
eax=00000000 ebx=e1cb0a48 ecx=00000000 edx=00000023 esi=00000000 edi=00000001
eip=a00257d6 esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003246
win32k!xxxScanSysQueue+0x123:
a00257d6 0f84ce070000 je win32k!xxxScanSysQueue+0x6d2 (a0025faa) [br=1]
... 100h == WM_KEYDOWN.
kd>
eax=00000000 ebx=e1cb0a48 ecx=00000008 edx=00000036 esi=00000000 edi=a0187e21
eip=a0025ff0 esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003246
win32k!xxxScanSysQueue+0x767:
a0025ff0 837dfc2c cmp dword ptr [ebp-0x4],0x2c ss:0010:f766fc88=0000002c
I think 2c is the scancode for print (or the VK_xxx) but I'd have to look that up.
kd>
eax=00000000 ebx=e1cb0a48 ecx=00000008 edx=00000036 esi=00000000 edi=a0187e21
eip=a0025ff0 esp=f766fbb8 ebp=f766fc8c iopl=3 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003246
win32k!xxxScanSysQueue+0x767:
a0025ff0 837dfc2c cmp dword ptr [ebp-0x4],0x2c ss:0010:f766fc88=0000002c
eax=f766fc2c ebx=e1cb0a48 ecx=00000008 edx=00000036 esi=00000000 edi=a0187e21
eip=a00c39e3 esp=f766fbb0 ebp=f766fc8c iopl=3 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003246
win32k!xxxScanSysQueue+0x1005:
a00c39e3 e8252ff6ff call win32k!xxxSkipSysMsg (a002690d)
SkipSysMsg is called, then
eax=a03106e0 ebx=e1cb0a48 ecx=f766fbd4 edx=00000001 esi=00000000 edi=a0187e21
eip=a00c3a2f esp=f766fbb4 ebp=f766fc8c iopl=3 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003206
win32k!xxxScanSysQueue+0x1051:
a00c3a2f e86efc0300 call win32k!xxxSnapWindow (a01036a2)
SnapWindow is called.
So, what do you want to do if you don't want a keyboard filter? A kernel hook on xxxSnapWindow?
|
|
|
|
|
Hi. Thank you for the help so far!!! It has been of great help!
It seems ill have to make, as you say, a kernel hook on SnapWindow...
Ill start working on it, although im relativly new to global hooks.
Any extra help would be appreciated!!
|
|
|
|
|
xxxSnapWindow isn't an exported function, so it's going to be hard to find since it's offset would be specific to any version of win32k.sys
My suggestion would be WH_KEYBOARD_LL, but I don't know what you're trying to accomplish. BTW, I hope this is for NT?
|
|
|
|
|
Well, first, its only supposed to work on win2000+, so no legacy problem.
Ive checked win32k.sys with PEView application and i didnt found, as you said, xxxSnapWindow as an exported function.
Keyboard hook is no good, cause the printscreen message might not come from the keyboard, but might come by a call from a 3rd party capture application, which i want to avoid.
Basically, i require an almost fail-proof mechanism to avoid screen capture in a specific window of my application. I have it all figured out when it's copied to clipboard, but when the capturing application saves it to file, i havent been able to stop it from happening. Other options could include a hook to a file write to disk, but that could have disasterouses consequences!!!
|
|
|
|
|
Ok, so you also want to stop screen captures from anyone taking a picture of your application. This will be tough, because an application could do this:
GetDC(NULL); and get a screen shot of the desktop without going through the code I showed. (Or get your window handle and do a copy).
Then, they just do:
BitBlt();
to their HDC and write it to disk or whatever they want.
So, there's more than one way to take a screen shot without having to push "print screen" button or emulate they are taking a snapshot with the function I showed.
SnapShot is also a kernel function, you planed to write a driver to fix this?
|
|
|
|
|
Yeah, ive checked a few things and there are a lot of ways that this can fail.
Regarding BitBlt(), i guess i could make a hook just for that, as it is a windows GDI function.
Reguarding SnapShot, i've been reading an article here on codeproject on how to make a kernel-mode spying driver. Ill eventually have to make it, as it will be essential in the following months to my app. Combining a lot of these protection, i might then be able to completly protect the system from screenshots, and, who knows, even sell the overall protection system
|
|
|
|
|
Hello, there, I got a C2065 compiler error. The error message is
error C2065: 'RBN_CHEVRONPUSHED' : undeclared identifier
But when I go to that line and right click on RBN_CHEVRONPUNSHED and then click on "Go to definition of RBN_CHEVRONPUSHED" I can actually go to the CommCtrl.h and see the definition. This is very strange.
How could I solve the problem?
Thanks a lot in advance
Bin
|
|
|
|
|
Your compiler knows where the file is, but your code is not including the file, so it doesn't. Include the file, and try again.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Thanks for your reply. I put the #include <commctrl.h> in the StdAfx.h file and also in that file with error. But I still got the same compiler error.
I am so confused.
Thanks again for your reply.
Bin
|
|
|
|
|
Not a solution, but a step. Is the error in your own code ? If so, try copying the #define into the top of your .cpp file and see if it compiles. If so, then it cannot see that file, for whatever reason. If not, the problem is somewhere else, and the error message is just not very helpful.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
I haven't tried this so I'm not sure it'll work, but try to define the _WIN32_WINNT macro as 0x0400 or later in stdafx right at the begining, before any other lines.
|
|
|
|
|
If you change something in stdafx.h you must recompile (manually) the file stdafx.cpp to update the precompiled header.
Robert-Antonio
"Love without sex is like a fish without antlers"
|
|
|
|
|
Hi all;
I am working on an SDI application and everything went fine until i tried to used some library to skin my application. I used the SkinMagic library and still everything is fine. The only problem is that i get a very ugly error each time i close my application (either by selecting the little X or by clicking the "Exit" button within my app).
The error reported is as follows:
The instruction at XXX referenced memory at YYYY. The memory could not be read. The debugger told me that it was an unhandled exception and pointed to a call to an assembly fx (i guess) called mov. It reported the error to be there.
Can somebody please help me out of this stuff. I really need to skin my application since it has to be nice-looking.
Ps. Anyway, if you know some cool way of skinning an application, could you please help me too.
Thank you;
Krugger.
Krugger
|
|
|
|
|
Sounds like you are closing your window, but neglecting to close down something the skin library requires you to shut down before your window handle is gone.
Check the skin library cocde for any explanaiton of tasks you must perform before your program has closed its main window. In your window's message handle, you can handle the WM_CLOSE message, and do the processing to shut down the skin library there.
|
|
|
|
|
hi
Kind of memory leak. chk the debug window to c the leaked memory segments and try to release those segments.
rgds ...mil10
|
|
|
|
|
hi
Kind of memory leak. chk the debug window to c the leaked memory segments and try to release those segments.
rgds ...mil10
|
|
|
|
|
I have a Batch file which run C-scripting commands. The firsy thing i does is to load a DLL dynamically.
This sets up a shared area for passing of data between this scripting function calss and a User Interface program (MFC C++).
The GUI program creates a Mutux for controlled access, this is stored in the shared area.
I have a problem, I can use the Mutux OK in the GUI application (WaitForSingleObject, ReleaseMutux etc. But in the DLL I wait forever for the Mutux, well 250 msec. The GUI is running with a timer ever 200 msec.
Are they a better way to have controlled access between the DLL and the GUI. Note the C-Script is calling functions in the DLL. Also the timer is causing some data not to be processed as already changed before Timer scheduled rouines to run.
grahamfff
|
|
|
|
|
What is Mutus? Are you saying mutex?
I don't think you need to store your mutex to shared area. Just use named mutex for your case.
Hope this helps.
Sonork 100.41263:Anthony_Yio
Life is about experiencing ...
|
|
|
|
|
I am trying to write a simple plugin using C++ but all the examples that i found were written in C#.
Does anyone have a C++ plugin sample that I can use to start with? Thanx a lot
|
|
|
|
|
|
|
Thousands of people use my program, and about every week a crash report is sent to me with the same details. Here's a picture showing the info from WinDbg: http://www.igx89.com/crash1.jpg[^]
(LogString is bound to an Edit Control using DDX_Text)
I can't figure out why that crash would be happening, and would greatly appreciate any help given to me.
|
|
|
|
|
ive had some problems concatnating cstrings in some programs... i never figured out y, but it happened very often, cause it was in a function used many times per second. The same code in another part of the program worked fine! The stupid part was that if i added some code in the same funtion, the problem disapeared! Seemed like a compiler error, maybe because of optimizations
|
|
|
|
|
The second use of + on that line appears to have faulted - you haven't shown the disassembly of ATL::operator+ , but if my copy of VS.NET has generated similar code, it looks like you've trashed the second argument, LogString . You probably have a wild write somewhere in your program.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
The only place where that variable is accessed is in the DDX call and in the function shown, so the variable should always be valid. I could probably work around the problem by using strcpy and strcat functions instead, but I'd rather discover the root of the problem so I don't have to worry about bugs like this popping up again in the future.
|
|
|
|