Tuesday 9 September 2008

In my last blog, I vented some of my frustrations and equal measures of eagerness to under the Component Based Servicing model used by Microsoft to update applications and their Vista and Windows Server 2008 platforms.

Cooler heads have prevailed, and a contact from our local media monopoly in the UK (hint: the BBC) sent me a link to a posting on the ASKPERF Vista Performance team blog ( Understanding Component-Based Servicing) that adds more detail to the rough Setup architecture sketch (see my previous blog post: Component Based Servicing)

The author CC Hameed indicates in his post that there are 6 key elements to the componentized services including;

  • CBS (Component Based Servicing) - Also known as the trusted installer (TRUSTEDINSTALLER.EXE), which works at the package / update level
  • CSI (Component Servicing Infrastructure) - Works at the deployment/component level
  • DMI (Driver Management and Install) – Advanced driver installation processes
  • CMI (Component Management Infrastructure) - Handles the advanced installers
  • SMI (Systems Management Infrastructure) – Used to manage registry settings
  • Kernel Transaction Manager (KTM) – Enables clients to use the transactional registry and file system

This is great!

Note the HINT that the TRUSTEDINSTALLER.EXE could be an alias for "CBS". Now, you can track down "TrustedInstaller" information easily as you can match the EXE/process name to the Service Name. Chris Jackson provides some really helpful hints on how to use the Services MSC (run services.msc) to track down these process. His blog is located here;  http://blogs.msdn.com/cjacks/default.aspx .

Running Services.msc from the command or start line, you get the following information regarding "Trusted Installer"



Two things stand out immediately;

  1. CBS looks like the Windows Module Installer. Could this be the same as MSI Installer? Is CBS just another name for MSI Packages
  2. And, look at that lovely directory; C:\WINDOWS\SERVICING\... I bet there are some DLL's we could have a look at here.

And YES! We found a little GEM... CbsApi.dll.

I am so excited, I feel like one of the characters from Dan Brown's book, "The Davinci Code" 

For this post, let's run this baby through a dependency analysis and then let's also see what DLL exports are visible... Yes, I am probably going to get into trouble from someone for this approach...

Here is a screen-shot from Depends.exe (we love you Mark: http://blogs.technet.com/markrussinovich )



No surprises here - and probably due to my lack of technical expertise in this area - no more useful information.

OK, now let's see what is in the DLL Export table - hopefully something interesting - something that will lead us to a little bit more knowledge.



Ohhh no, just the standard DLL Self Register API calls... Arrgghh.... Nothing, no new information....

Oh, you little CBS, I am really going to get you now... 

1 comment:

Unknown said...

Hey, i got the same issues and found something new. I'm a Delphi developer and there i'm able to import ActiveX Libaries to get the Interface functions.

Because i saw inside the SmiProvider.dll that there is some activex code in visual text inside the .dll!! I just imported this dll as ActiveX and got luck! It created a new file for me and a DismLib_TLB, too! This DismLib contains 2100 lines of interface code with all functions that exist with parameters etc.

Now just figure out how to use them in the correct order and all will be fine ;)