|
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.
|
|
|
|
|
I assume LogString is a member of the CFLModManager class.
I don't think your problem is with a legitimate access; I think something else is corrupting the object. Possibilities I can think of are: you're using the CFLModManager object after it's been deleted (if you're using new/delete to manage the object), or from another thread or routine outside the scope of the function that declares the object (if it's a local variable), or that you have an unbounded ('wild') write somewhere which is overwriting the memory used by the LogString object.
The first two cases are relatively easy to check for. The last really requires examining every memory access in the program that could possibly coincide with the life-time of the dialog box. You can help yourself out a little by putting a data breakpoint on the LogString member and see when it changes. Specifically, it appears to be the m_pszData member that's been corrupted.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Yes, it's a member of the main dialog class, CFLModManager. I don't see how the first case would be possible; the second case might, I guess, but I just have one other thread, and it just communicates using SendMessage to the main thread's window. I'll try changing it to PostMessage (not sure if that'll do anything), and increasing a couple buffers that aren't CString's (I doubt they're overflowing, but just to be sure).
What makes this crash so hard to debug is that I can't duplicate the crash, and it rarely happens to my users; ~1 crash a week (auto-reported) out of 10,000+ downloads. Fortunately, because it's so rare, it won't be that big of deal if I can't fix it; I don't think it's happened to the same person more than once.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
