I’ve found that when I make a call to SetSecurityInfo, VC’s debugger reports
a thread has exited. But my multithreaded program continues to have a
constant number of threads with the same thread ID’s before and after the
call. It’s as if SetSecurityInfo is creating a temporary thread within my
process to do some work - but I can’t find any documentation which supports
that.
Any ideas? Any RTFM on this topic?
RLH
At 05:11 PM 11/14/2000 -0800, you wrote:
You could prove/disprove your theory by using Windbg. Run to
SetSecurityInfo & then set Windbg to break on thread create (sxe ct)
then go. If SetSecurityInfo creates a thread then you should breakin.
Then you can step & see what it is doing.
I’ve never used WinDbg before, but here’s what I found:
-
The “sxe ct” command isn’t accepted, at least not in the command window.
The “sxe” command is recognized, but the “ct” parameter doesn’t appear to be.
-
By setting a breakpoint on the call to SetSecurityInfo and the line
immediately after, I am indeed able to confirm that a thread is created and
terminated within my process space while within the call to SetSecurityInfo.
Now, I’d like to read some documentation on WHY a thread is created and what
it’s doing. I accept that a thread is being created by SetSecurityInfo, but
I’d like more information on that topic.
Thanks!
RLH
> call. It’s as if SetSecurityInfo is creating a temporary thread within my
Why not? If this is an RPC call (like LookupAccountName or NetUserEnum) -
than this is very real.
Max