Max:
You are another victim of a special thread handling in MFC. When a thread
terminates, DLL_THREAD_DETTACH
is passed to the app’s main entry. Most of the “pure” Win32 apps simply
return TRUE for this mesage. MFC apps, instead,
allocate some per-thread data that must be deallocated during
DLL_THREAD_DETTACH handling. Things are event worst,
because MFC per-thread data is used in many MFC-derived objects. In all
CWnd-derived objects for sure. There is another
sign of the same problem. If in MFC app you create a thread not via
AfxBeginThread (or something), but via CreateThread or
_beginthread, you will not be able to use most of the MFC objects in context
of that thread.
Vladimir
-----Original Message-----
From: xxxxx@paragon.ru [mailto:xxxxx@paragon.ru]
Sent: Friday, February 25, 2000 11:52 AM
To: NT Developers Interest List
Subject: Re: [ntdev] Creating threads in context of user process from the
kernel
Once again. I DO NEED this thread after the application exits. I’ve just
stolen the context of the application and then don’t need this application
anymore. A user works with the application not knowing about the spy kernel
thread. Non-MFC applications doesn’t react on that fact that there are
additional threads appear. But MFC applications want to control all the
threads of the process, they don’t react on the kernel threads while working
but they cause access violation when exiting.
Regards,
Max
??: Jamey Kirby[SMTP:xxxxx@storagecraft.com]
???: NT Developers Interest List
???: 25 ??? 2000 ?. 20:22
???: NT Developers Interest List
???: [ntdev] RE: Creating threads in context of user process from the
kernel
If the thread is in the context of your application, when your application
goes away, so does your thread. Because you are not properly synchronizing
the removal of the thread, you are experiencing the problem you are seeing.
I have doen this myself. You need to terminate the thread when the
application terminates (in IRP_MJ_CLOSE or an IOCTL send by the application)
and re-cresate it in the process you need when you need it againt. Sorry to
dissapoint you.
This has been my experience.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@paragon.ru]On Behalf Of
Max Lyadvinsky
Sent: Friday, February 25, 2000 8:55 AM
To: ‘NT Developers Interest List’
Subject: Re: [ntdev] RE: Creating threads in context of user process
from the kernelThis isn’t the way, 'cause I need this system thread.
??: Jamey Kirby[SMTP:xxxxx@storagecraft.com]
???: 25 ??? 2000 ?. 19:26
???: NT Developers Interest List
???: [ntdev] RE: Creating threads in context of user
process from the kernelYOu need to terminate tht thread in your driver first.
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Max Lyadvinsky
> Sent: Friday, February 25, 2000 6:34 AM
> To: NT Developers Interest List
> Subject: [ntdev] Creating threads in context of user process from the
> kernel
>
>
> Dear All!
>
> I’ve encountered the following problem in my nt driver. Inside my
> driver I create threads in the context of the user mode
> application and when the application exits the access violation
> occurs. This occurs just in MFC applications. The MFC application
> tries to deallocate resources for each thread and faults.
> I can work around this problem by terminating the main thread (in
> CWinApp::ExitInstance) when exiting my MFC app, but in this case
> global destructors are not called. Maybe there is a way to tell
> the MFC app about the newly created kernel mode thread so that
> the MFC application could exit without problems?
>
> Regards,
> Max Lyadvinsky
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
You are currently subscribed to ntdev as: xxxxx@paragon.ru
To unsubscribe send a blank email to $subst(‘Email.Unsub’)