Reason #124 to update your Platform SDK from time to time

by Michael S. Kaplan, published on 2005/03/18 03:53 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/18/398479.aspx

Antti Nivala asked in the microsoft.public.platformsdk.mslayerforunicode newsgroup:

Our software uses MSLU. I noticed that if I run our programs with Application Verifier 2.50 with the Handles test enabled, I get a bunch of Invalid Handle exceptions during module loading. In the end, these prevent the program from running. The call stack points to MSLU. If I rebuild the program without MSLU, the Invalid Handle exceptions no longer appear.

Is this a known issue? Is it OK, or is MSLU (or I) doing something that is not perfectly OK?

Note that I am not saying that MSLU would have caused any real problems in the normal use of our program. I just want to confirm why the Handles test of Application Verifier 2.50 fails if MSLU is used.

Here's some relevant output from WinDbg:

===========================================================
VERIFIER STOP 00000300: pid 0xCD8: invalid handle exception for current stack trace

 00000000 : (null)
 00000000 : (null)
 00000000 : (null)
 00000000 : (null)
===========================================================

(cd8.d14): Invalid handle - code c0000008 (!!! second chance !!!)
eax=c0000008 ebx=7c8097ad ecx=0012fde4 edx=7c90eb3d esi=00000001 edi=7c800000
eip=7c90eb74 esp=0012fd90 ebp=0012fde0 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000 efl=00000206
ntdll!KiRaiseUserExceptionDispatcher+0x37:
7c90eb74 8b0424           mov     eax,[esp]
ss:0023:0012fd90=c0000008
0:000> kb
ChildEBP RetAddr  Args to Child
0012fde0 7c90eb93 7c90d9eb 7c83928f 00400000 ntdll!KiRaiseUserExceptionDispatcher+0x37
0012fe00 004577dc 00400000 004a5864 00000004 ntdll!KiFastSystemCallRet+0x4
0012fe3c 00456b67 00484cec 00484fb0 004a5864 MFStatus!ResolveThunk+0xc9 [d:\xpclient\sdktools\unicows\delay\resolve.c @ 188]
0012fe90 0045cb59 004a81d0 00000fa0 7c80b529 MFStatus!kernel32_GetProcAddress_Thunk+0x1f [d:\xpclient\sdktools\unicows\delay\thunk_stub.c @ 46]
0012fea4 0045c977 00459336 00000094 00000005 MFStatus!_mtinitlocks+0x2b [f:\vs70builds\3077\vc\crtbld\crt\src\mlock.c @ 133]
0012fea8 00459336 00000094 00000005 00000001 MFStatus!_mtinit+0x5 [f:\vs70builds\3077\vc\crtbld\crt\src\tidtable.c @ 117]
0012ffc0 7c816d4f 7c911978 ffffffff 7ffdf000 MFStatus!wWinMainCRTStartup+0xe0 [f:\vs70builds\3077\vc\crtbld\crt\src\crt0.c @ 184]
0012fff0 00000000 00459256 00000000 78746341 kernel32!BaseProcessStart+0x23

Thanks in advance!

Antti

This is a bug I was pretty sure I was familiar with, so I asked "What version of the .LIB are you using?". Antti replied:

I think it was from Platform SDK July 2002 edition. Anyway, I upgraded to using the LIB version that ships with Platform SDK February 2003 and the problem disappeared.

Thanks :-)

Antti

Yep, that was the problem. It has to do with the MSLU loader (contained in unicows.lib) which does the following:

1. Takes its bunch of data segments, one per API that might be called, with all of the necessary info for the API (the name, the name of the "stub" function to call if the API cannot be found, a pointer to our ResolveThunk() function, etc.).
2. The first time an API is called, ResolveThunk() is called with all the API information in #1.
3. ResolveThunk() figures out what API should be called. It fixes up that pointer to itself, changing it to the actual API.
4. Call FlushInstructionCache() to flush out any cached information for the modified code in the change to #3
5. All future calls to the API go directly to it, making ResolveThunk() a "call once per API" function.

The problem with this bug is that it turns out step #4 was not needed, so the call was pretty much ignored on all platforms. Unfortunately, the handle being used in the call was not valid for the call to FlushInstructionCache() and AppVerifier is an application that works hard to find such problems.

The fix was simple enough -- just remove the call to FlushInstructionCache. It was doing nothing other than breaking AppVerifier anyway.

The bug was customer-reported (customers use our tools, even if we do not always do it  :-) ), and I had the fix in the next Platform SDK....

The moral of the story? Update your Platform SDK from time to time -- it may fix impotant bugs! :-)

This post brought to you by "！" (U+ff01, FULLWIDTH EXCLAMATION MARK)

# Nektar on 18 Mar 2005 4:51 AM:

# Michael Kaplan on 18 Mar 2005 8:01 AM:

# Dean Harding on 20 Mar 2005 7:18 PM:

john on 5 Jun 2008 2:17 PM:

referenced by

go to newer or older post, or back to index or month or day