Using SetConsoleCtrlHandler
in [Win32 Kernel]
|
Prev: Hook chain using TEB->Win32ThreadInfo
Next: HOMEDRIVE, HOMEPATH missing in CreateEnvironmentBlock
From: Skywing [MVP] on 6 Jun 2007 22:49 Yes, that should be the same for anything that calls CreateThread/CreateRemoteThread to spin up a user mode thread. It appeared as if you were suggesting that the ctrl handler was invoked via an APC queued to a pre-existing thread, which as far as I know, is not the case. -- Ken Johnson (Skywing) Windows SDK MVP http://www.nynaeve.net ""Jeffrey Tan[MSFT]"" <jetan(a)online.microsoft.com> wrote in message news:IGelA4KqHHA.2304(a)TK2MSFTNGHUB02.phx.gbl... > Hi Ken, > > Thank you for sharing your thought. > > Actually, if I remember correct, all the CreateThread(CreateRemoteThread) > goes into the kernel and created the kernel-mode thread structures, > finally, kernel will initiate a user-mode APC to return control to the > user-mode. Then user-mode will resolve this user APC by executing > kernel32.dll!BaseThreadStart(). Sorry, I did not check the root cause of > who called CreateThread(CreateRemoteThread). > > Anyway, my key point in the reply is the second paragraph. > > Thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > Get notification to my posts through email? Please refer to > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > ications. > > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > where an initial response from the community or a Microsoft Support > Engineer within 1 business day is acceptable. Please note that each follow > up response may take approximately 2 business days as the support > professional working with you may need further investigation to reach the > most efficient resolution. The offering is not appropriate for situations > that require urgent, real-time or phone-based interactions or complex > project analysis and dump analysis issues. Issues of this nature are best > handled working with a dedicated Microsoft Support Engineer by contacting > Microsoft Customer Support Services (CSS) at > http://msdn.microsoft.com/subscriptions/support/default.aspx. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no > rights. >
From: "Jeffrey Tan[MSFT]" on 6 Jun 2007 23:32 Oh, yes, thank you for the clarify. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
From: Emmanuel Stapf [ES] on 7 Jun 2007 00:32 Thanks for the feedback and the link to the other discussion thread, it was very helpful. We will see if we end up implementing this solution or something else. Regards, Manu
From: Tony Proctor on 7 Jun 2007 05:38 The difference there is the fact that the code must be in an alertable state Gary. There are several possible mechanisms for an event-driven client-side application but if it's server-side then this requirement makes the "interrupt" less than responsive. In my case, the code was being ported from elsewhere and wasn't event-driven (in the Windows sense) or even had a message pump. I admit to not having used APCs though. If the APC queue were examined when a thread starts executing (i.e. after leaving a wait state, or being taken off the ready-to-run queue) then it would be ideal, but I don't believe it's implemented at that level Tony Proctor "Gary Chanson" <gchanson(a)No.Spam.mvps.org> wrote in message news:O$s$jsDqHHA.4132(a)TK2MSFTNGP02.phx.gbl... > My solution for a similar situation was to redirect the exception to the > appropriate thread using a User APC. In my case, I can be reasonably > certain that the task will enter an alertable state within a reasonable > time, so this works very nicely and is a lot cleaner they your alternative. > > -- > > - Gary Chanson (Windows SDK MVP) > - Abolish Public Schools > > > > "Tony Proctor" <tony_proctor(a)aimtechnology_NoMoreSPAM_.com> wrote in message > news:eFnX5$BqHHA.1148(a)TK2MSFTNGP06.phx.gbl... > > Windows is not very good at handling this sort of asynchronous interrupt > on > > a single thread Emmanuel (i.e. similar to UNIX signals, or even VMS ASTs) > > > > The question has been asked before: > > > http://groups.google.ie/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/608ad10204f76515/1e175f06dca6106f?hl=en#1e175f06dca6106f > > > > I've even found myself in the same boat in trying to port a language, and > > its framework, to the Windows O/S. In the end, I suspended the thread, > read > > its context, redirected it to a point that would generate the required > > exception, and then released it. Surprisingly, it worked OK in practice > > (although not on Alpha AXP H/W) but there were a few issues with win32 api > > calls that had to be addressed (mentioned in that old thread) > > > > Tony Proctor > > > > "Emmanuel Stapf [ES]" <manus(a)newsgroups.nospam> wrote in message > > news:uQhAUi9pHHA.1144(a)TK2MSFTNGP02.phx.gbl... > > > Hi, > > > > > > I've a console single threaded application and I'm trying to catch a > > Ctrl+C. No > > > matter if I use SetConsoleCtrlHandler or a signal handler, my code to > > handle > > > this gets called in another thread. Is there a way to have the handler > > called > > > from the main thread? > > > > > > In the code below, simply comment the call to `signal' or to > > > `SetConsoleCtrlHandler' to observe the similar behavior. On Unix, using > > > `signal', it is called from the same thread. > > > > > > Thanks for any highlight, > > > Manu > > > > > > PS: this is shown by the code: > > > > > > #include <windows.h> > > > #include <stdio.h> > > > #include <signal.h> > > > > > > BOOL CtrlHandler( DWORD fdwCtrlType ) > > > { > > > switch( fdwCtrlType ) { > > > case CTRL_C_EVENT: > > > printf( "Ctrl-C event\n\n" ); > > > return TRUE; > > > default: > > > return FALSE; > > > } > > > } > > > > > > void handler (int sig) { > > > printf ("From Signal\n"); > > > signal (SIGINT, handler); > > > } > > > > > > void main( void ) > > > { > > > signal (SIGINT, handler); > > > //SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE ); > > > > > > printf("Use Ctrl+C to see what is going on.\n" ); > > > while( 1 ){ } > > > } > > > > > >
From: Tony Proctor on 7 Jun 2007 05:40
....actually, I don't suppose anyone knows how things like SIGINT are implemented in the POSIX sub-system under Windows. Do they even work like a UNIX developer would expect? Tony Proctor "Gary Chanson" <gchanson(a)No.Spam.mvps.org> wrote in message news:O$s$jsDqHHA.4132(a)TK2MSFTNGP02.phx.gbl... > My solution for a similar situation was to redirect the exception to the > appropriate thread using a User APC. In my case, I can be reasonably > certain that the task will enter an alertable state within a reasonable > time, so this works very nicely and is a lot cleaner they your alternative. > > -- > > - Gary Chanson (Windows SDK MVP) > - Abolish Public Schools > > > > "Tony Proctor" <tony_proctor(a)aimtechnology_NoMoreSPAM_.com> wrote in message > news:eFnX5$BqHHA.1148(a)TK2MSFTNGP06.phx.gbl... > > Windows is not very good at handling this sort of asynchronous interrupt > on > > a single thread Emmanuel (i.e. similar to UNIX signals, or even VMS ASTs) > > > > The question has been asked before: > > > http://groups.google.ie/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/608ad10204f76515/1e175f06dca6106f?hl=en#1e175f06dca6106f > > > > I've even found myself in the same boat in trying to port a language, and > > its framework, to the Windows O/S. In the end, I suspended the thread, > read > > its context, redirected it to a point that would generate the required > > exception, and then released it. Surprisingly, it worked OK in practice > > (although not on Alpha AXP H/W) but there were a few issues with win32 api > > calls that had to be addressed (mentioned in that old thread) > > > > Tony Proctor > > > > "Emmanuel Stapf [ES]" <manus(a)newsgroups.nospam> wrote in message > > news:uQhAUi9pHHA.1144(a)TK2MSFTNGP02.phx.gbl... > > > Hi, > > > > > > I've a console single threaded application and I'm trying to catch a > > Ctrl+C. No > > > matter if I use SetConsoleCtrlHandler or a signal handler, my code to > > handle > > > this gets called in another thread. Is there a way to have the handler > > called > > > from the main thread? > > > > > > In the code below, simply comment the call to `signal' or to > > > `SetConsoleCtrlHandler' to observe the similar behavior. On Unix, using > > > `signal', it is called from the same thread. > > > > > > Thanks for any highlight, > > > Manu > > > > > > PS: this is shown by the code: > > > > > > #include <windows.h> > > > #include <stdio.h> > > > #include <signal.h> > > > > > > BOOL CtrlHandler( DWORD fdwCtrlType ) > > > { > > > switch( fdwCtrlType ) { > > > case CTRL_C_EVENT: > > > printf( "Ctrl-C event\n\n" ); > > > return TRUE; > > > default: > > > return FALSE; > > > } > > > } > > > > > > void handler (int sig) { > > > printf ("From Signal\n"); > > > signal (SIGINT, handler); > > > } > > > > > > void main( void ) > > > { > > > signal (SIGINT, handler); > > > //SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE ); > > > > > > printf("Use Ctrl+C to see what is going on.\n" ); > > > while( 1 ){ } > > > } > > > > > > |