8 Mar
2005
8 Mar
'05
11:11 a.m.
Hartmut Birr wrote:
I can fix my problem by protecting the access to some
entries of the
object header with a global spinnlock, but I doesn't like this. Has
anyone a better idea?
I don't like it either. If this fixes your problem, it means it will affect
performance and power usage negatively (else it would have no effect for
you).
I think we might be barking up the wrong tree here, working around a problem
in the registry code (?) by adding bloat and slowing-down code to one of the
central code "services". One particular reason I believe that, is the
following I just put together from looking at what NT5sp4 seems to do.
That's btw also all it does - nothing else. Feel free to play with and
commit it.
{
if (Header->ObjectType != ObjectType /* type mismatch */&&
(AccessMode != KernelMode /* but mismatches are OK i kmode */ ||
ObjectType == ObSymbolicLinkType /* so long as we're not requesting a
symbolic link */))
{
return STATUS_OBJECT_TYPE_MISMATCH;
}
}
InterlockedIncrement(&Header->RefCount);
}
/Mike
P.S. I think a global replacement s/ObSymbolicLinkType/ObpSymbolicLinkType/
could be prudent (adding the "p").