A question came up in one of the comments asking me to please define TrustedInstaller. I've talked about it before a few times, but I've never gone through and dug through the implementation in a visible way. Time to change that - and we can do so with the help of some built-in command line tools, with a little power assist from Sysinternals.
Here's the dialog you can have with these tools to illustrate how this works, so you can see it rather than just reading somebody tell you about it:
c:\Windows>REM What does the ACE actually say?
c:\Windows>icacls explorer.exe explorer.exe NT SERVICE\TrustedInstaller:(F) BUILTIN\Administrators:(RX) NT AUTHORITY\SYSTEM:(RX) BUILTIN\Users:(RX)
Successfully processed 1 files; Failed processing 0 files
c:\Windows>REM OK, let's get the SID for that...
c:\Windows>psgetsid "NT SERVICE\TrustedInstaller"
PsGetSid v1.43 - Translates SIDs to names and vice versa Copyright (C) 1999-2006 Mark Russinovich Sysinternals - www.sysinternals.com
SID for NT SERVICE\TrustedInstaller: S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
c:\Windows>REM This SID is one of the new Service SIDs in Windows Vista
c:\Windows>REM How do we verify which one? sc.exe has a new option
c:\Windows>sc showsid TrustedInstaller
NAME: TrustedInstaller SERVICE SID: S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
c:\Windows>REM yep - it's the same one! How does this appear in the
c:\Windows>REM services MMC console?
c:\Windows>sc getdisplayname TrustedInstaller [SC] GetServiceDisplayName SUCCESS Name = Windows Modules Installer
c:\Windows>REM And there you have it - here's the principal you're looking for
I had a comment come up on an earlier post:
"FYI, I've hit a limitation with CorrectFilePaths - the maximum amount of data that can be entered in the parameter field is 512 bytes - not enough to fix more than 2 files under "Program Files" unfortunately..."
Now, I knew the limitation existed, but I had never spent the time to understand the exact limitation, or where it existed. Is the limitation in Compatibility Administrator when it generated the XML for the SDB compiler? If so, we could always be sneaky and edit the XML before the compiler was run. Is the limitation in the SDB compiler? It's a lot more work, but if so we could always be sneaky and reverse the SDB format to add additional information. Or is the limitation in the shim engine itself, which makes being sneaky quite challenging indeed?
And the answer is that the limitation is in the shim engine itself. We can see that with a bit of reverse engineering.
The API that the shim engine calls happens to be publicly documented, so that makes our job easier. It's SdbReadStringTag. Here's where we actually pull the command line:
0x6C105914: 6800040000 PUSH 0x400 0x6C105919: 56 PUSH ESI 0x6C10591A: 50 PUSH EAX 0x6C10591B: FF7508 PUSH DWORD PTR [hSDB <Void *>]; ARG:EBP+0x8 0x6C10591E: 66891E MOV WORD PTR [ESI],BX_IS_ZERO0x6C105921: E865260000 CALL __imp__SdbReadStringTagRef@16; (0x6C107F8B) ; SdbReadStringTagRef
Since this is a __stdcall function, arguments are passed right to left. The first PUSH, therefore, corresponds to __in DWORD cchBufferSize, and this is what limits the command line.
So, we know that the command line is limited to 0x400 characters (1,024), and the limitation is implemented in the shim engine itself.
Shims that require longer command lines, such as CorrectFilePaths, you therefore need to be careful with. If you can shorten the command line by only taking the portion of it you need, that is helpful. If you can leverage file and registry virtualization for fixes, that leaves you more of your 1,024 characters to work with as well!
If you run the Internet Explorer Compatibility Evaluator on Windows Vista, you get back some data when an ActiveX control tries to write to a file that a standard user used to be able to write to. However, that data doesn't show up when you are using the Internet Explorer Compatibility Test Tool.
Why?
It's configured not to.
Um ... I don't know? (Perhaps because the quality of the output is qualitatively different than every other test in the tool?)
But I do know how to turn it back on.
Open up Notepad elevated, and then open up "C:\Program Files\Microsoft Application Compatibility Toolkit 5\Internet Explorer Compatibility Test Tool\IECEConfig.xml".
If you then search for the word EXCLUDE, you'll find this:
<EXCLUDE>VirtualizationAction:AcTraceIgnored;</EXCLUDE>
Just comment this out (or delete it) and we'll stop excluding data from the view. Now your tool is configured to stop hiding data that must be useful. Is it perfect? Nope - it doesn't collect it all. But at least it shows you what it did collect.
Why doesn't it collect it all? I don't know, but I can speculate. The Internet File System and Internet Registry are implemented on IE7 using shims (specifically, shims sitting in acredir.dll, such as RedirectFiles and RedirectRegistry). While most of IECE's output is based on the browser itself, the browser would have to predict what the shim infrastructure was doing. While you can turn on shim diagnostics and pull some of this out depending on the debug spew and log spew the shim writer included, that really complicates things. So, unlike rules where the browser explicitly knows "hey, I'd have to do this bad thing which the following code will specifically prevent, better log it" here we have API interception happening at a completely different layer where the browser code would have to either attempt to predict (could have false outcome), hook into the shim infrastructure, or parse ACLs and duplicate security logic.
But the things we are detecting, we really ought to show, wouldn't you agree?
8-Aug-2008: Added details on my abbreviations (per comment)
7-Aug-2008: Updated to fit the table into the width of the column for web readers...
...And I'm back. I've been conspicuously absent for a while because I was furiously preparing for TechReady 7 (an internal conference for the Microsoft field), and during the middle of that conference I decided to break my arm. I've been reviewing my scores publicly for a while to elicit external feedback, so I figured I'd continue that trend here.
The sessions I delivered were:
Shims1: CLI315 - Mitigating Application Issues Using Shims Part 1
Shims2: CLI403 - Mitigating Application Issues Using Shims Part 2
Debugging: CLI400 - Debugging Application Compatibility Issues
PjM1: CLICT300-R1 - Application Compatibility Project Best Practices
PjM2: CLICT300-R2 - Application Compatibility Project Best Practices (Repeat)
Once again, let's take a look at my ratings relative to my peers. Last time I was looking specifically within the Windows Client track but this time around let's compare scores to the conference as a whole:
And some of the comments:
"This was the best and what i had expected out of every technical session at TR. thanks for skipping the marketing decks!"
"GREAT presentation without PPT. Other presenter have to do the same. We are here to see how it's working, not print screen."
"I appreciated the demo-centered approach to presenting. Chris has a wealth of knowledge and he is a very good teacher."
"This was the only true 400 level content of all the classes that I did attend. This was beyond my skill level, but the presentation skills of the presentor kept me awake and interested"
"I loved it, hardcore to the bone!"
"I lack most of the pre-req skills to really take advantage of the insight & info presented in this session. 20 years ago when I joined MS I was very good at Dissasembing Apps. I've not used it since. So I'm skilled enough to see he did a great talk & also to realise that I'd need a lot more coaching before I could replicate what he showed me. Great Talk."
My learning:
Dispensing with the PowerPoints is goodness. That's right. PPT, be gone with you from my technical sessions! They're still there for you to take home, but I don't need to read to you. I took my shim sessions, which have traditionally done fairly well, and rocketed them up to the top of the entire conference by just doing away with PPT. #2 session in the conference, #1 on 4 attributes (including overall). Pure goodness.
You can go too hard-core. Debugging Application Compatibility Issues was a top session in the conference, but I didn't leave enough breadcrumbs for folks. You should walk away from every talk knowing something more than you did when you came in. If you walk away feeling like you can't do any of that, then it's just a show, and not educational. Fun, but almost as helpful as a box of hair. Take it from deep to deeper to deepest - don't just start way in the depths with a screen full of assembly language.
I'm not so good at chalk talks. Now, to be fair, I did deliver one with an untreated broken arm, but I think the scores speak for themselves even for my able bodied session. I tried to make it interactive because I wanted feedback on project management, but clearly I should bring in talent better suited for that goal.
I need to make sure to keep it relevant. The scores aren't horrible here, but they're the weakest link. Perhaps I should start polling the audience more. And, for anyone attending an upcoming conference, feel free to tell me what matters to you. I'm trying to base what people are interested in by the questions that get funneled my way, but I'll communicate with you any way that I can.
Thanks again to anybody who attended - I hope you enjoyed the demos and the absence of PPT! See some of you at TechEd EMEA! (And perhaps at PDC - that's not locked in yet.)
I've got a pile of topics to cover that have backed up in the queue, so now back to your regularly scheduled geekiness...