As the only way to disable the CTRL+ALT+DEL sequence under NT (and W2K as well) is to write a "keyboard filter driver", does anyone have some practical example to do that? Thxs, -=Cip=- This message was edited by Cip, on 5/17/2001 4:48:18 AM
Posted on 2001-05-17 04:47:00 by Cip
sorry Cip, but you're wrong! I already tried writing a lowlevel keyboard hook but it was not possible to disable ctrl+alt+del keys. the ONLY possibility is programming a GINA.DLL. You'll find information about that on the microsoft site. You have to choose Security/Winlogon or something to find a example and documentation.
Posted on 2001-05-17 09:16:00 by [SaFc0n]
Safcon, what you say it's correct. I've already tried a low-level keyboard hook, and it didn't work. But searching on Internet, I've found at the end of the MS LowLevelKeyboardPrc example the following sentence:
NOTE: Although a low-level keyboard hook gets notified when CTRL+ALT+DEL is pressed, it cannot prevent the CRTL+ALT+DEL from being handled by the system. Another option available is to install a keyboard filter driver, that can prevent keystrokes from being sent to the system, including CTRL+ALT+DEL. Consult the Windows NT DDK documentation for more information on keyboard filter drivers.
I've tried to "Consult the Windows NT DDK documentation", but at the end I was completely lost. I've started to use MASM32 one month ago, and I'm really enthusiast about the results. I've converted the current program that I'm developing to ASM, but now I have to add a feature to disable the CTRL+ALT+DEL sequence during a user session (the BlockInput API will do the rest). As I'm a newbie, a concrete example would be appreciated. That's why I posted the message here...
Posted on 2001-05-17 10:05:00 by Cip
sorry, i didn't know that, and i don't have a sample source. but if you manage it to disable the keys, please contact me..... thank you very much in advance
Posted on 2001-05-17 14:57:00 by [SaFc0n]
could you answer me this: why would you want to do this? MS blocked the interception of these keys for a valid reason. What benevolent reason could you have not wanting people to use them?
Posted on 2001-05-17 15:30:00 by Hiroshimator
Hiro, I was expecting a question like that. And here is the answer: The program that I'm currently developing, it's an application used in a "Software Distribution" environment (Tivoli). This app checks some dependencies on the workstation, prompt a message to the user and starts the installation script. It's a Global application (1 neutral language exe + x satellite resource dlls (one per language, 24 in total (for the moment))), to prompt the message to the user in the correct language. As I said that it starts the installation script, well... the user receive the message to agree to start the install phase a then press "OK"; after that, I disable the inputs, as during the installation I don't want any user interaction. It's not really user-friendly, I know, but it's a good solution in a large environment (eg. when you update Outlook, and you leave to the users to opportunity to play with the PC, also if you say them "Please don't use Outlook during the installation period", a lot of them will start Outlook). Sorry for the complex explanation, I hope now it's more clear what I want to do ;-) This message was edited by Cip, on 5/18/2001 3:10:42 AM
Posted on 2001-05-18 03:07:00 by Cip
I personally think you're driving it too far. Users can do a lot of things, including turning of their PC while installing, going away and expecting it to be installed after they return. I've seen that with my own eyes :eek: There's only so much you can do, best thing is to warn them and built in checks in your program. It's MS fault that you can start outlook while their updating it. Why doesn't it work via mutex to create just a single instance then or via a registry key? And hey if they still want to be stupid just scare the hell out of them saying things like: don't touch anything while installing or your hard drive might corrupt ;) (then you see them thinking: oh no my pr0n! :( And they usually don't even dare to touch the keyboard ;)) I've done support does it show? :D This message was edited by Hiroshimator, on 5/18/2001 4:43:47 AM
Posted on 2001-05-18 04:43:00 by Hiroshimator
Hiro, I understand what you are saying... ...but let me explain something more about the environment and give you some numbers: In my company, before this Global project, there was two different approch to this problem. In Europe (where I am) I implemented the input locking (changing the registry keys HKLM\SYSTEM\CurrentControlSet\Services\Kbdclass & .\Mouclass, value "Start" to 4 before the install & back to 1 after the install), but this implementation requiered two reboots (obviuosly done automatically). In the US, was implemented a more user friendly procedure, like the one you suggested. (The rest of the world hasn't implemented any Software Distribution, waiting for this Global project...). Then, the results: Europe: installation failures due to locked files: 0% pc switched off during the installation: 10% United States: installation failures due to locked files: 30% pc switched off during the installation: 2% (that's strange, but it seems that when a user doesn't have the "cancel" button, he replaced it with the "power" switch) Feedbacks: Europe: "The installation is taking too long!" (because of the 2 reboots) US: "The installation is fast and transparent, but sometimes the PCs have some strange messages and some applications don't start anymore" And, with the last update to the workstations, that was Internet Explorer, the US guys adopted the European method (and the PCs switched off during the installation were only 5%). So, probably the best solution (this is my opinion, and someone can disagree), is to: - Install, rebooting the PC only when is requiered. - Lock the inputs, after the user agreed on the installation - Warn the user during the installation (to prevent the switch off) And I know that it's possible to lock inputs during a user session with an appropriate driver (like some remote control tool like PCAnywhere or VNC). A I'd like to implement it... at least to improve my personal knowledges.
Posted on 2001-05-18 05:42:00 by Cip
Cip: You asked:
As the only way to disable the CTRL+ALT+DEL sequence under NT (and W2K as well) is to write a "keyboard filter driver", does anyone have some practical example to do that?
I have (within the past six months) finished up with a project at my work which involved the writting of a keyboard filter driver that would run on both NT and 2K (program work's like a champ). While I was doing research on the project I came across the following link, which I am sure will benefit you as-much-as it did me: kernel-mode driver that demonstrates keyboard input filtering just above the keyboard class driver Granted the source file is in C but it is a trivial thing to convert (if you need help in doing so just let me know and I can scrap the job related stuff from a few of the test conversions of this program that I did and send them your way) Hope this helps. -- MadPrgmr --
Posted on 2001-05-18 12:50:00 by madprgmr
Thanks MadPrgmr, with the link you gived me I have now a good starting point. I've download the source, so in this weekend I've something to work on ;) As you said, to convert it from C to ASM it's not so simple... So, any help would be appreciated... my e-mail is: BTW I won't be able to connect to Internet before Monday...
Posted on 2001-05-18 14:16:00 by Cip