On 16/03/2011 19:37, Ryan Johnson wrote:
> On 2:59 PM, Henry S. Thompson wrote:
>> Ryan Johnson writes:
>>
>>> BTW, I found a good way to identify, if not fix, BLODA: given an app
>>> which loads no libraries at runtime -- such as 'ls' -- any dlls
>>> mentioned in /proc/$$/maps which cygcheck does not mention are
>>> probably dodgy. In my case, Windows Live (which I didn't think was
>>> even installed on my machine) has injected a WLIDNSP.DLL ("Microsoft
>>> Windows Live ID Namespace Provider") in all my processes.
>> This would be super-cool if true, but it doesn't work for me. . .
>>
>> If I try, I find
>>
>> C:\Windows\system32\ntmarta.dll
>> C:\Windows\SysWOW64\sechost.dll
>> C:\Windows\syswow64\WLDAP32.dll
>>
>> in /proc/[ls procid]/maps but not in cygcheck output, but none of
>> those are BLODA, right?
>>
>> [Note also that maps shows many things in syswow64 which cygcheck
>> shows in system32, but presumably that's because cygcheck itself is a
>> 32-bit app, is it?]
>>
> Interesting...
>
> $ join -i -v 1 <(cat /proc/$$/maps | sed 's;^.*/;;' | sort -f) <(cygcheck
> $(cat /proc/$$/winexename) | sed 's;^.*\\;;' | sort -f)
[list cut]
>
> The above shows all dlls loaded by the process which are not linked in at
> compile time. Does bash really load so many dynamic libraries, or is cygcheck
> missing things?
system DLLs dyamically load other DLLs, both for extensibility and for
performance (delay-loading), so this list doesn't really tell you anything
interesting.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
