Maarten's blog

Disabling a Shim (part II)

2009-07-29T19:15:18Z

Follow-up from the research on how to disable a per-application shim. When I saw the output from the shim infrastructure in DebugView, I mistakenly assumed that the application was shimmed. It apparently only means that the application is found in the AppCompat system database. It does not mean that the shim is actually still in place.

Which leaves me with the question, how do I easily verify that an application is not shimmed (short of the earlier mentioned shotgun approach of turning the whole shim engine off)? Someone who does this for a living told me that one way you can tell is whether aclayers.dll is loaded in the process. He also told me that getting an application shim free is not that easy. There are all kinds of watchdogs in the system monitoring and instrumenting applications.

When an application entry is disabled in ACT, I see with Process Explorer two environment variables that indicate to me they have something to do with Application Compatibility or shimming: __COMPAT_LAYER = VistaSetup and SHIM_DEBUG_LEVEL = 9. The last one was added by me for the logging. I also see AcGeneral.dll and apphelp.dll loaded in the process. And it is wrapped in a job (you can tell by looking at the process properties in Process Explorer; there is a Job tab).

When I reenable the entry, I see __COMPAT_LAYER=VistaSetup WinXPSp2_GW and the same SHIM_DEBUG_LEVEL=9. This WinXPSp2_GW matches the entry in the ACT database. This somewhat confirms that disabling an entry does indeed have the desired effect. Also an additional dll was loaded: the before mentioned aclayers.dll.

When the PCA notices your application as a setup, it will flag it in the registry. This was my case and I was thinking maybe, the VistaSetup CompatLayer comes from there. I made sure the application was not flagged anywhere under (\AppCompatFlags\Compatibility Assistant\Persisted.) No difference. VistaSetup was still there.

Then I disabled the Program Compatibility Assistant service. The effect of that was that the process is no longer wrapped inside a job. However the service restarts quickly. I had to disable it to make sure it didn't get in the way. Still the VistaSetup was there as an environment variable.

My current assumption is that the VistaSetup layer is coming from the fact that there is no Windows 7 switchback entry in the manifest. It apparently is also detected as a setup. I will need to verify it by adding the switchback GUID. That is for next time.

Logo doc

2009-07-29T03:09:00Z

When I go to connect and download the Windows 7 Software Logo Requirements v1.7.docx, it downloads a zip file. Unzipping the file gives me a somewhat familiar view.

I've seen this before. This looks like a OPC document. Since OPC is XML wrapped in Zip format it would make sense. I renamed the file to docx. Now I can open it.

By the way, what is really nice is that apparently Wordpad is the default handler for docx files on Windows 7.

Windows 7 Software Logo Voucher

2009-07-28T23:43:11Z

For Windows Vista Logo, we used to have vouchers to entice early adaption. An ISV recently asked me for vouchers for Windows 7. Since Windows 7 is a "self-test" there is no need for a voucher. It is virtually free. The only cost might be that an ISV needs to buy a certificate to log in to winqual (which is where you would submit your test results).

https://connect.microsoft.com/site/sitehome.aspx?SiteID=831

What happened to my Search

2009-07-28T00:56:54Z

I recently upgraded to Windows 7 RTM. When I hit the Windows key, no search results were being returned. Only standard items from control panel etc. The Windows search service appeared not to be running. When I tried to start the service from services.msc, I got an error:

Windows could not start the Windows Search service on Local Computer.

Error 1224: The requested operation cannot be performed on a file with a user-mapped section open.

Since those things always happen when you're urgently working on something else, I decided to just uninstall and reinstall Windows Search from "Turn Windows Features on or off". After a reboot, I was surprised to find that hitting the Windows key resulted in the start menu opening without the search box. It is also fascinating how reliant one becomes on just typing a couple of initial characters and getting a list of suggestions from search. Now I had to reinstall and figure out where that was again. (I normally type Windows Key, then "features" to select Programs And Features. Now I had to navigate the control panel.

After reinstalling Windows Search, still (somewhat luckily) the same error. OK. Grumpf. All other projects put aside. ProcMon.

Starting Process Monitor and then trying to restart Windows Search. When the error above pops up, I stopped Procmon. Now filter in ProcMon only on SearchIndexer.exe (the executable name of the Search service). Most of the files that are used by the service either return "SUCCESS" or "FILE LOCKED WITH ONLY READERS". But then I found this result "USER MAPPED FILE". That looked somewhat in line with the error. The path of the file was

C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Projects\SystemIndex\Indexer\CiFiles\0001000C.wid. When I tried to use Windows Explorer (first enable viewing Hidden and System files) I had some interesting flickering issues. Folder contents would show up in the right-hand pane, only to disappear with a fraction of a second. One can only investigate so much at a time though. Moving on.

With an elevated command prompt I was able to get to the file. I moved the file to my desktop. Restarting the service and Eureka. In the event log a whole bunch of errors and warning were logged. Windows Search complained about the index being corrupt (most likely because the offending file was missing).

But search is back and running again.

Performance Impact of /IntegrityCheck

2009-07-24T03:44:16Z

You can link binaries with /integritycheck. This will tell the loader to check the signature of the binary at load time. Supposedly signing with page hash (/ph) has a substantial impact on load time. Omitting /ph will require the entire binary to be loaded in order to calculate the hash and verify the signature. I assume /ph does it over the pages as the name implies.

From "Kernel Data and Filtering Support for Windows Server 2008":

"All ISV kernel and user mode modules must be linked with the /integritycheck flag set at link time. This will cause the memory manager to enforce a signature check at load time for the referenced code. This link.exe setting is present in recent versions of the Microsoft Visual Studio® linker. If the ISV is using alternate tools to link or edit their produced binaries, this flag setting has the effect of setting (ON) IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY (0x0800) in the image PE header OptionalHeader.DllCharacteristics field.
Digitally signed user mode modules must have cryptographic per-page hash catalogs. These are generated using the /PH command-line setting to the signtool utility."

You add /integritycheck in the Visual Studio linker options in advanced. You can verify in a binary editor that the actual flag is set. I used CFF Explorer.

In order to sign, I create a demo certificate:

Makecert -r -pe -sr localMachine -ss demostore -n "CN=DemoCert" democert.cer

Then you can use signtool.exe to sign the binary with that certificate.

Signtool Sign /v /s demostore /n DemoCert /t http://timestamp.verisign.com/scripts/timestamp.dll <mydlltosign>.dll

I created to binaries: one signed with /ph and another without. On trying to load the /ph binary I got an error saying the binary was invalid. I checked the signature and all was good. I signed an executable with the same certificate, UAC elevated it and the consent dialog had the signed flavor. Hmm. Cert was added also to the trusted store.

From "AppInit DLLs in Windows 7 and Windows Server 2008 R2":

"The DLL must be signed with the /ph (page-hash) option. Page-hash enforcement verifies the signature on each page as it is loaded into memory. Because of this requirement, the DLL must be signed on a system that is running Windows Vista or a later version of Windows. The DLL should also be signed with the /t (timestamp) option to prevent the digital signature from expiring when the code-signing certificate expires. When you release sign the DLL, you must use the /ac option to reference a cross-certificate. This is required because the signing code path exists in the Windows kernel, which has a hard-coded root of trust. The cross-certificate is required to chain to the issuing certificate authority."

It appears that integrity checking bypasses the trusted store. Most likely for performance reasons but that is my guess. You need to cross link with a Microsoft certificate. Since I didn't have one handy (and I have no idea how one would do it), I rebooted and turned off driver sign checking. Low and behold my binary loaded.

The actual performance part was not as easy as hoped. I used x-perf. But difference between the page-hash signed binary and the no page hash signed binary was inconclusive. Most likely because my binaries were too small.

Next time I have a free morning, I'll dive into it.

Disabling a Shim

2009-07-24T02:30:13Z

The other day I was working on an application that we apparently shimmed. I wanted to know if disabling the shim actually changed the behavior.

You can download ACT and go hunt for the executable. (For some interesting reason that fully escapes me, you should uncheck every checkbox in the Query dialog to get the search to find anything at all.) When I found the entry and disabled it, there was no change in behavior. That doesn't mean the shim was still in place though. So I needed to know for sure.

Digging up the expert knowledge from "the" apcompat guy, gave me the info for getting the logging enabled. Hooking up DebugView and I still see the shim applied. Even flushing the cache didn't prove helpful (Rundll32 apphelp.dll,ShimFlushCache). Hmm. Sledgehammer then.

You can disable the whole shim engine through this setting from GPEdit.msc:

Administrative Templates \ Windows Components \ Application Compatibility \ Turn off Application Compatibility Engine

Setting it to enabled means that the Shim engine is off. Reboot and there you have it. No output in DebugView.

Now I need to figure out why I can't disable this thing on a per shim entry basis.

Running Idle tasks before XPerf

2009-07-22T00:41:49Z

I am working on profiling impacts of software on the performance of the OS. I'm testing on Windows 7 RC 7100 x86. It is predominantly to get a feel for the complexity. I want to know how much effort it would entail to wrap this up into an offering for our partners. I'm running it in a Hyper-V VM but it should give me a solid idea.

Last week I spent most of the time with my colleague Mark installing and getting DTM to run. Mark has done this way more and his relentless demeanor gets him into territories that give me nightmares. DTM is one of them but we got it done and I feel somewhat comfortable running the tests.

The COSD performance guys have put some nice performance tests together. They ship with the WLK under SPPT. Some of the tests under there can't be run under virtual machines (hibernate), but others can. So I ran three tests: 15 minute idle, boot and shutdown. While I still need to make sense out of the gathered data, one thing I noticed in one of the 15 minute idle traces is a 2% CPU hit by rundll32.exe. Digging through the tons of data that xperf provides, I was able to find that this was in effect System Restore.

Going back through "Measuring Performance on Windows Vista", it is noted there that you can either wait three days or run "rundll32 advapi32.dll,ProcessIdleTasks". That helped.

Application Verifier Locks 0x201 Active Critical Section

2008-10-16T05:17:15Z

Suppose you are trying to get your application Vista Certified or OEM Ready. You test your application with Application Verifier and you see this error in the log:

"<avrf:logEntry Time="2008-10-15 : 14:18:33" LayerName="Locks" StopCode="0x201" Severity="Error">

<avrf:message>Unloading DLL containing an active critical section.</avrf:message>

Now what? From the log, this is difficult to debug.

Little history how you might have arrived here. When you checked the Basics errors in Application Verifier, you got a warning mentioning something along the lines of "For the basic tests you need a debugger". This is because Application Verifier sets break points. If you don't have a default debugger, those breakpoints are ignored hence you need a debugger. Best thing you can do is run your application from the debugger: preferably Windbg since that has some useful extensions that help you navigate the process' memory. You can download it here. After installing and running you can under File | Open Executable navigate to your application. Hit F5, reproduce the error and break into the debugger.

Next best thing is to set Windbg as the interactive debugger (Windbg –I from elevated command prompt). When the application sets a break point (the application verifier layer in this case), the system will see if there is an interactive debugger. If it finds one, it launches it with your application as the target.

Good. So now both ways have taken you to this point:

(11e4.1604): Break instruction exception - code 80000003 (!!! second chance !!!)
eax=000001ff ebx=75988844 ecx=77dde7c4 edx=00000000 esi=00000000 edi=000001ff
eip=77db0004 esp=003ee8fc ebp=003eeafc iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
ntdll!DbgBreakPoint:
77db0004 cc int 3

You of course need symbols. I explained how here.

Now comes the interesting part. Learn and appreciate the power of "!analyze –v":

0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** WARNING: Unable to verify checksum for e:\Playground\AVRF\x201\Debug\x201b.exe
APPLICATION_VERIFIER_LOCKS_LOCK_IN_UNLOADED_DLL (201)
Unloading DLL containing an active critical section.
This stop is generated if a DLL has a global variable containing a critical section
and the DLL is unloaded but the critical section has not been deleted. To debug
this stop use the following debugger commands:
$ du parameter3 - to dump the name of the culprit DLL.
$ .reload dllname or .reload dllname = parameter4 - to reload the symbols for that DLL.
$ !cs -s parameter1 - dump information about this critical section.
$ ln parameter1 - to show symbols near the address of the critical section.
This should help identify the leaked critical section.
$ dps parameter2 - to dump the stack trace for this critical section initialization.
Arguments:
Arg1: 718933cc, Critical section address.
Arg2: 00f8a104, Critical section initialization stack trace.
Arg3: 05be6fe4, DLL name address.
Arg4: 71870000, DLL base address.

The information is fairly self explanatory. In the process a dll is loaded. This dll initializes a critical section and then before deleting the critical section, the dll is unloaded. There are four parameters which are useful mentioned above. And then some complaining about symbols; followed by more useful information. (I think it complains about symbols because it wants private symbols for the OS. I don't have those, but the results are good anyway.)

Somewhere halfway, you'll find this:

CRITICAL_SECTION: 718933cc -- (!cs -s 718933cc)

So this is the actual critical section we're leaking. Clicking on the hyperlink gives us:

0:000> !cs -s 718933cc
-----------------------------------------
Critical section = 0x718933cc (<Unloaded_TheLib.dll>+0x233CC)
DebugInfo = 0x05c2afe0
NOT LOCKED
LockSemaphore = 0x0
SpinCount = 0x00000000

Stack trace for DebugInfo = 0x05c2afe0:

0x77df99b6: ntdll!RtlInitializeCriticalSectionAndSpinCount+0x19
0x75976936: vfbasics!AVrfpInitializeCriticalSectionCommon+0x136
0x75976ab2: vfbasics!AVrfpRtlInitializeCriticalSection+0x12
0x71881f37: <Unloaded_TheLib.dll>+0x11F37
0x7188bc28: <Unloaded_TheLib.dll>+0x1BC28
0x5e82c02c: MSVCR90D!_initterm+0x1C
0x71883131: <Unloaded_TheLib.dll>+0x13131
0x7188351e: <Unloaded_TheLib.dll>+0x1351E
0x71883451: <Unloaded_TheLib.dll>+0x13451
0x75a059c9: verifier!AVrfpStandardDllEntryPointRoutine+0x109
0x75a7859d: vrfcore!VfCoreStandardDllEntryPointRoutine+0x127
0x7598105e: vfbasics!AVrfpStandardDllEntryPointRoutine+0x10E
0x77dcfcc0: ntdll!LdrpCallInitRoutine+0x14
0x77dd9b28: ntdll!LdrpRunInitializeRoutines+0x270
0x77dd95ae: ntdll!LdrpLoadDll+0x4D5
0x77df29db: ntdll!LdrLoadDll+0x22A
0x7598164c: vfbasics!AVrfpLdrLoadDll+0x5C
0x75fc4d50: kernel32!LoadLibraryExW+0x231
0x75fc4dca: kernel32!LoadLibraryW+0x11
0x00f42d50: x201b!Cx201bDlg::OnBnClickedButton1+0x30

Hmm. Of course. The dll is gone. Which is kind of the crux of this problem. The bold line indicates where the critical section was initialized. If you have multiple critical sections, you might scratch your head which one you're leaking here. So you can try to reload the dll. There is a little snippet how you should be able to do this with .reload etc. I have never been able to do this. If you have, let me know.

What I do is spin up an instance of the application in the debugger and make sure that the dll is still loaded. (You can set breakpoints on LoadLibrary to make sure that you are just after the load, and before the Free. Subject for another blog potentially.) Then, I do a ln (as in list near) with the address from the bold line in the stack trace.

0:001> ln 71881f37
*** WARNING: Unable to verify checksum for E:\Playground\AVRF\x201\Debug\TheLib.dll
e:\playground\avrf\x201\thelib\thelib.cpp(49)+0x11
(71881ef0) TheLib!CTheLibApp::CTheLibApp+0x47 | (71881f70) TheLib!CTheLibApp::`scalar deleting destructor'

There we go. Thelib.cpp(49). Looking at that source line, takes me to the InitializeCriticalSection call of the problematic critical section.

Maarten

Debugging and Symbols

2008-10-16T04:33:58Z

Anytime you want to do anything in a debugger, you need symbols. Best thing you can do is set up an environment variable, so you're done. Here are public Microsoft symbols. Yves has created a little cmd that you can use which I politely copy here since it is handy:

SetX.exe /M _NT_SYMBOL_PATH "SRV*C:\Symbols\Private*\\Symbols\Symbols;SRV*C:\Symbols\Public*http://msdl.microsoft.com/download/symbols"

And for more information there is a KB article.

DllGetClassObject already defined

2008-09-12T01:51:03Z

When you upgrade your project from VC2005 to VC2008 you might get these errors:

mfcs90u.lib(oleexp.obj) : error LNK2005: _DllGetClassObject@12 already defined in d.obj
mfcs90u.lib(oleexp.obj) : error LNK2005: _DllCanUnloadNow@0 already defined in d.obj

Strictly in release builds though.

You can add "AFX_MANAGE_STATE(AfxGetStaticModuleState());" to the first line of InitInstance() in dllmain.cpp.

Application Verifier Logs for a Service

2008-08-20T21:35:59Z

If you have a service and have told AppVerifier to monitor it, you might wonder where the logs are and how you can see them. (Two separate questions). You can find the logs here "c:\windows\system32\config\systemprofile\appverifierlogs" (or the corresponding directory given the system drive and bitness of your application).

Now if you want to see them in AppVerifier, the easiest way is to just copy them over to the current user profile and then do a view logs from AppVerifier.

OEM Ready Links

2008-08-20T19:18:38Z

While I'm trying to find out how to fix the portals, here are some links to documents we frequently use.

OEM Ready program: http://msdn.microsoft.com/en-us/windowsvista/cc315067.aspx
There is a Manual for the tool, but it is not linked from anywhere as far as I can tell: http://go.microsoft.com/?linkid=9093231
Here is Jay's video on Channel 9: http://channel9.msdn.com/posts/philpenn/The-Microsoft-OEM-Ready-Certification-Tool/

Shared Components

2008-08-20T00:43:04Z

If you need to install components that are shared between multiple applications, you want them to go to Common Files. I found a decent description in this doc: "Windows Vista Application Development Requirements for User Account Control Compatibility".You should stay out of system32.

How Do I know if Windbg I actually took effect?

2008-07-11T00:59:20Z

So you're ready to test your application with Application Verifier. The OEM Ready and Certified for Windows Vista (CFWV) test documents specify you type Windbg –I from an elevated command prompt. So you add your application to Application Verifier, add the specific tests under basic and miscellaneous and start your app. You run through your "normal operations" and exit the application. Nothing happened.

Now you have a lingering doubt: did my app not trigger any AppVerif breakpoints? Or did I not set it up right? Hmm.

Here is a little test app. Copy this in a C command line app and build; add the application.exe to AppVerif as in the test steps and it should break in with a NULL handle stop code 303.

#include "stdafx.h"

#include "windows.h"

int _tmain(int argc, _TCHAR* argv[])

{

HANDLE h = NULL;

WaitForSingleObject( h, 0 );

wprintf(L"Okiedokie\n\r");

return 0;

}

How to Roll Back WinDbg –I

2008-07-10T23:50:16Z

For OEM Ready tests (and for Certified for Windows Vista) one of the requirements is to set up an interactive debugger. The documentation specifies Windbg since it allows you to do use extensions such as "!analyze –v" which will give you a ton of information. One question that then comes up is "How do get back my machine back to its original state before I ran WinDbg –I?"

Those are the registry keys in question that "WinDbg –I" changes:

\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
\\HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug

When you set WinDbg –I, Windbg will add a new string value "Debugger" with a path to windbg.exe. There is also an Auto string value added.

The recommendation is to back up the registry key before running WinDbg –I. On one of my clean systems the key was existent but the Debugger and Auto values were missing. Removing those effectively rolled back my system to the state it was in before. But don't take my observation as official guidance.

On a final note, if you absolutely don't like WinDbg, you can use Visual Studio as your interactive debugger. Under Tools/Options/Debugging you will find a Just-In-Time section. If you click the "Native" checkbox, your application will break in to Visual Studio when a breakpoint is encountered.