The Streaming Profiler is the application that “captures” installation program content.   A simple view, the profiler’s mission is to observe the activities of an installation program (disk/registry), prevent them from really happening and finally, to write down everything that the installation program thought should be done to the machine.   The whole time, the installation program BELIEVES that it has truly installed things just like at runtime under the Streaming Client, the executed application will believe that everything it needs for execution is present, even when only a subset is there.

From an isolation view, this activity of “profiling” is very-very similar to the activity of running isolated applications.   The Streaming Profiler though has many extra jobs such as extracting the icons of the application that was “installed” and making them available for the publishing system.  It also examines the isolated “Start Menu” to see what additions the installation program “thinks” it made to the system.  These additions become the list of detected applications that are part of the profile.  There is lots of other stuff going on such as simulating reboots and otherwise figuring out what the installation program was trying to accomplish.  All of these are neat things, but they are not the focus on this blog.

Where does the profiler put the temporary stuff?

This is a question I get a lot.  People are well familiar with the “3 layers of isolation” chart that I have shown before in other posts.  During profiling, there are only 2 layers and the layer that is missing is the “user space”.   In a way, the layer missing is the middle layer, but it fundamentally doesn’t matter, there are only 2 layers during profiling.  The installation image during profiling is “writable”.  At runtime, the installation image is read only and there is an extra “pane of glass” laid down to handle the per-user space.

During normal Streaming Client runtime, the installation image is “cached” below the \Program files\Citrix\RadeCache directory.  During profiling, these same directories are not used!  They are not used on-purpose to avoid any messing up by profiling and running applications at the same time.

Right – where’s the stuff?

The Streaming Profiler ALSO deletes everything when it closes profiles, or when the Streaming Profiler application is terminated.  WHY?  Why not?  It was temporary stuff.  This does make the content harder to find if you go looking for it AFTER you close the profiler.  In more realistic scenarios, this deleting of the temporary content is what allows the Streaming Profiler to profile hundreds of installers without rebooting the machine.  This is very handy for conferences where the show floor can “show and tell” profiling all day long without rebooting.

Right, where’s the temp space?

Two things are needed to reflect the layers of glass of isolation.  The disk redirection and the registry redirection.

DISK:    %TMP%\Citrix\Packager

REG:     HKLM\Software\Citrix\AIE

Update: Feb 2010

  • Above accurate through version 5.2 of the profiler.
  • In later versions: DISK location changed to %SystemRoot%\<!– /* Font Definitions */ @font-face
    Unknown macro: {font-family}


    Unknown macro: {font-family}

    /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal

    Unknown macro: {mso-style-unhide}


    Unknown macro: {mso-style-type}

    @page Section1

    Unknown macro: {size}


    Unknown macro: {page}


Here’s a snapshot of the disk and registry profiling locations on my notebook.
Registry temporary space during profiling

Can I mess with it?

Answer: Sure!

Should you mess with it? No!

Long answer: Not unless you have a good reason!   In theory, there is no reason to mess with the content of these directories/registry while profiling.  BUT – People have asked about it, so they must have a good reason – or maybe just be curious.

When running the Streaming Profiler, the profiler GUI will open .profile files off of network servers.  Or, maybe it will create new profiles.  Either way, the GUI sends instructions to the profiler “back end” (radepkg.dll), which does the heavy work of operating on profiles.

When a profile is opened, nothing related to the execution targets is in the temp editing space.  Only when a Target is placed into edit state does the CAB file contents get unzipped into the temp space and the registry contents get extracted.  All the activities of profiling then work to “modify” this temporary space and when the profile is saved, the execution target is then “zipped up” (cabbed up?), into the image that is stored on the network server.  While the Profile/Target is being edited, the contents of the disk and registry are “fair game” for being messed.  Again: Should you?  No!  But, if you do mess with the extracted contents of the profile in the temporary space, while the profile is being edited, the changes you make WILL be captured and saved with the profile.  Like all back doors, don’t expect the internal operation of the Streaming Profiler to be the same from release to release, but in concept, this process has worked so far.

Saving your changes…

Just because you modify things behind the back of the streaming profiler does not mean that the Streaming Profiler will save your modifications.  If the profiler back end believes that “nothing changed”, it will optimize the cab up and save portion of the editing to “do nothing” and this will abandon your changes.  The easiest way to convince the profiler that “stuff changed” is to launch an installer that does nothing.  My favorite is CMD (command prompt) – and then “exit”.  Having launched an installer, the profiler back end will be convinced that the execution Target has been modified and will include that Target during the save.

A better way

The better answer is to use the Streaming Profiler SDK.  You’re trying to do programmatic stuff anyway, so why not do it from a program?  Even better, using the SDK will insulate you from changes in implementation of the streaming profiler.  More information on the profiler SDK can be found here.  What it comes down to is a COM interface into the profiler back end (the plumbing, not the GUI).   This is an area ripe for more discussion, so I’ll put that on the list of things to write about.

What about all those subdirectories?

Right, those are my fault.  Though MSI and other installation tools normally have a limit of one active instance at a time, the Streaming Profiler does not.  That is, multiple instances of the Streaming Profiler *CAN* be opened at once and from the view of the profiler, all don’t know about the others.  Eventually, MSI prevents multiple concurrent profiling, but that’s a limitation of the installation system, not of the Streaming Profiler.

Why bother with this?  Don’t know, it seemed like a good idea at the time.  The good news is that you can open one profile for reading and open another for really profiling stuff and the streaming profiler back end will deal with keeping all the items separate.  Well, that’s the theory at least, this multiplicity of profiling has not seen significant exercise in the field, but the profiler back end supports it.

Consider that when a profile is created, the back end has to store the data for that profile, but that the profile does not yet have a name.  The name is only assigned during SAVE and this lack of a name is a big headache for the back end.  The PROFILE is edited and the Targets of that profile can be edited.

When the profile is edited (happens immediately when you open the profile in the Streaming Profiler), the profile contents are placed into edit space (build location) in a PKG_n directory/key below the top locations noted earlier in this post.  (Example: PKG_1).  If PKG_1 already exists, the back end moves on by bumping the number until it finds a whole that isn’t being used by some other profiler.  Eventually, it gets a hit and that’s the number space for the profile that is being edited.

When the Target of a profile is created, or edited, the back end needs to extract its contents to temporary space so that the “layers of glass” can be constructed and so that the Target can otherwise be edited.  Targets are identified by their GUIDs, so it would make sense that the GUID is the key for storing the Target’s contents.  It WOULD make sense, except….   The Target’s GUID is assigned when it is created – and then CHANGED when the Profile is SavedAs.  The Profile also has a GUID that receives must less attention, but it is still there.

On a SAVE, the GUIDs are retained and the version number of the Targets is incremented.

On a SaveAS, the GUIDs are changed.

The first save of a new profile (a created profile) is always a SaveAs, so the GUIDs are useless for storage of temporary content.

Since the GUID cannot be used as the key for the directory, the same low tech unique name is used as is used for the profile.  Temporary directories for the target are TGT_n and stored below the top space described earlier.

In HRP1, during “Finalizing your profile”, the profiler back end would CAB up the contents of the Target and place it into the PKG_n directory and then the PKG_n directory would be copied to the destination location, presumably on a file server.   I just tried this in the upcoming Delaware level code and the intermediate step seems to have been optimized out by the Streaming Development team – I send kudos.

If you go to edit things while they are being edited, then you’ll find the good disk stuff below one of the TGT_n directories and the registry contents below the AIE key.  Be sure to close out your editing program or it will prevent the Streaming Profiler from deleting the temporary space when it terminates.

Cleaning up

If the Streaming Profiler “dies” mid streaming – right, this would never happen!, but if it did, there can be “stuff” left around in the temp space.  Future executions of the Streaming Profiler will treat those left around directories as “it must be someone elses” and they will go for a bigger number until they get their own space for profiling.

You can SAFELY obliterate the Disk contents used by the profiler temporary storage, at any time that you are not profiling.

Example command:

RD /s /q  “%TMP%\Citrix\Packager”

Registry temporary space used in profiling is actually in the same space as AIE execution on PS 4.0 servers and PS 4.5 servers.  Cleaning up these (where the profiler didn’t do it for you) is a bit more work.

The keys to whack are below HKLM\Software\Citrix\AIE.  If you’re not on a PS server or not on a PRODUCTION server, you can use this command to delete the temporary AIE space.

reg delete hklm\software\citrix\aie

In my experiment, some of these keys aren’t going away.  There’s a lock held!  Hum.  In theory, they can go away.

I don’t know if stuff like this is useful for the general community.  Mostly I expect it to be useful for the streaming developers, but they already know it already.  If you find this useful or want some more details, let me know.

Joe Nord
Product Architect Application Streaming
Citrix Systems, Fort Lauderdale, FL