Detecting OS loader lock
Christoph Lindemann
I was wondering, if there is any way to detect if code is executed within
the OS loader lock. (Entered by LoadLibray and similar)
http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx
http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx
I would like to add some checks to some of my libraries, so I can raise an
assert exception, when executed within the loader lock.
--
Christoph Lindemann
Jeffrey Tan[MSFT]
Internally, OS loader lock is maintained in the PEB. But, we should not
look at the loader lock value in the PEB, not even for debugging purposes,
and especially not in libraries which might be reused.
In general, making any assumptions about undocumented system state is a
recipe for app compat problems down the line.
The recommended way is using AppVerifier. AppVerifier has checks that make
sure DLLs aren't doing anything wrong in DllMain. I think you can also run
with these checks on when running from Visual Studio with AppVerifier.
There's also a whitepaper on DLL best practices at
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b183365
65f5b/DLL_bestprac.doc.
Hope this helps.
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.
Christian Kaiser
We just faced a problem with multiple threads and a loader lock. One thread
did end, releasing a DLL (not from us) as a side effect (which means getting
the loader lock). Inside this THREAD_DETACH, the DLL called
GetProcAddress(), which in turn did trigger a DLL of ours, which in turn
tried to aquired a CriticalSection internally (which protects a list of
modules). This is because we need own skinning and we need to catch
GetProcAddress() calls.
Not the other thread did aquire the CriticalSection and did try to get the
module's handle (GetModuleHandle(), innocent enough), which internally tries
to get the loader lock.
Duh. Deadlock.
Knowing the loader lock we'd know we max not call some system APIs.
We have a workaround for this special case, but this just works around this
special case.
And the morale of the story: while it's fine to say that the loader lock is
none of our business, and we should stay clear to any of these issues
internally, we cannot rely on other DLLs to behave the same way, so we (as
developers) should be able to check that lock to avoid the chances of
deadlocks due to interoperability! Especially not in multithreaded
environments.
If this were that easy, why was "TryEnterCriticalSection" ever programmed?
For the same reason it would be very nice (yet years too late!) to either
get the loader lock's state, or a "try" version of critical APIs like
GetModuleHandle().
Christian
""Jeffrey Tan[MSFT]"" <je...@online.microsoft.com> wrote in message
news:nZcZyrHD...@TK2MSFTNGHUB02.phx.gbl...
Christoph Lindemann
> For the same reason it would be very nice (yet years too late!) to either
> get the loader lock's state, or a "try" version of critical APIs like
> GetModuleHandle().
Exactly, this would at least make it possible to "fail gracefully", instead
of ending up in a deadlock - which potentially could go unnoticed for quite
a while until your customer wonders why nothing is happening (Kinda "no
entries in the event log, the service runs, everything looks ok -> hmm why
do no orders arrive?" situation)
Best regards,
Christoph
Christoph Lindemann
> look at the loader lock value in the PEB, not even for debugging purposes,
> and especially not in libraries which might be reused.
I disagree, especial for debugging purposes. It would be very helpful to be
able do determine if a piece of code is executed within the loader lock,
instead of having to look at stack traces and making assumptions on what
routines might have entered the loader lock (which probably differs a lot
from win version to version, or between service packs). Even worse if some
third-party DLL created an additional thread.
The idea is not to make a library which code depends on the loader lock for
taking one or another path. Its more to be used as a tool to determine "what
went wrong". This get even more important these days where it is typical to
use all sorts of third-party libraries (DLL's) for which there is no way to
be sure that their developers did it "the right way". Or what if your app
can load plug-in dll's provided by a third-party and installed by you
customer. There is no chance that you can assure that dll (which you do not
know) will not f... up, the only thing you get is a customer which
complaints that your application does not work.
While I see a good reason to comply with the guideline for dllmain routines,
and generally do as little as possible within it, I do not see how being
able to query the state of the loader lock can hurt?
> In general, making any assumptions about undocumented system state is a
> recipe for app compat problems down the line.
Being able to query the loader lock state would provide the opposite, in my
view. I would be able to determine the state correctly, instead of being
forced to make assumptions or qualified guesses about the state, based on
what functions where called.
> The recommended way is using AppVerifier. AppVerifier has checks that make
> sure DLLs aren't doing anything wrong in DllMain. I think you can also run
> with these checks on when running from Visual Studio with AppVerifier.
> There's also a whitepaper on DLL best practices at
> http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b183365
> 65f5b/DLL_bestprac.doc.
While this is all very nice for preventing loader lock problems in the first
place, it can only be used for ones own in-house dll's. It will not help you
determine what went wrong when your application hangs at a customers site,
due to some third-party dll.
> Hope this helps.
Well, no; it was not quite what I had hoped for :)
Best regards,
Christoph
Doron Holan [MSFT]
change from release to release, so if you can inspect it and derive state,
it becomes a huge app compat nightmare when we want to change the
state/semantics in the future. by bleeding out state, it creates fragility
and unnecessary cohesion between the OS and loaded modules.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Christoph Lindemann" <clind...@newsgroups.nospam> wrote in message
news:%23eB41tL...@TK2MSFTNGP03.phx.gbl...
m
all circumstances. This can be challenging, but in my experience, all
_unsolvable_ problems can be solved by a change in design.
"Christoph Lindemann" <clind...@newsgroups.nospam> wrote in message
news:%23eB41tL...@TK2MSFTNGP03.phx.gbl...
Christoph Lindemann
"Doron Holan [MSFT]" <dor...@online.microsoft.com> wrote in message
news:uxUDqFPD...@TK2MSFTNGP06.phx.gbl...
> the problem here is that the state/semantics of the loader lock can and do
> change from release to release, so if you can inspect it and derive state,
> it becomes a huge app compat nightmare when we want to change the
> state/semantics in the future. by bleeding out state, it creates
> fragility and unnecessary cohesion between the OS and loaded modules.
I understand why you do not want to expose this, but problems with the
loader lock are very difficult to trace down. Especially if thirdparty dlls
are involved.
I am not interested in doing all kind of hacking and tweeaking, and make
"intelligent" code which tries to repair programming faults in thirdparty
plugins.I am just interested to get notified about the problem. So the
program can stop, crash, whatever. Just hanging in a deadlock with no way to
detect why and where, is just not good enough.
In the .Net 3 framework there is an managed debugging assistant for the
loader lock. Something similar would be nice for win32.
Why cant the LoadLibrary, GetProcAddress just fail and return an error, or
if code to detect deadlocks might be a problem here - it would also be nice
if the functions could return a timeout error. Soething like TryLoadLibrary,
like Christian Kaiser writes.
This would not prevent me or others from doing bad implementations, but at
least we would be notified that we f.... up, and then we could take action.
I know not tempting the "mighty loader lock" is the best way to evade any
confrontations in the first place, but sometimes you have to and other times
you just happen to do crude or stupid stuff (or at least it happens to me
sometimes). And it would be nice if it would tell me in the face, if I
happen to violate it, instead of giving me the silent treatment.
--
Christoph Lindemann
Christian Kaiser
example)b but not easy to cope with if you have no chance to find a perfect
solution, as you'll only know you've got a problem with the loader lock when
you see your program in a deadlock ;-(
Christian
Sergei Zhirikov
http://msdn2.microsoft.com/en-us/library/bb432187.aspx
"Christoph Lindemann" <clind...@newsgroups.nospam> wrote in message
news:%23khhSL%23CIH...@TK2MSFTNGP06.phx.gbl...
Christian Kaiser
But the docs are the usual "Undocs" which tell nothing reliable.
"Indicates whether the caller is holding a synchronization
primitive.". The "one and only", or just "a primitive"? Is this the
one we need? What with Win64?
The newer Docs are near to worthless ;-(
Christian
"Sergei Zhirikov" <sf...@yahoo.com> wrote in message
news:OuYIEVVK...@TK2MSFTNGP02.phx.gbl...