SetSecurityInfo creates/destroys threads?

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:

  1. 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.

  2. 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