Updated bits (v1.6g)  are being posted on the Microsoft Download Center and should be available shortly.

First let me apologize for the length of time since my last post.  Unfortunately this post is to report that UPHClean is now officially dormant.  Release bits for UPHClean v2.0 are not forthcoming.  There's no plan of record for release. This means that even if it was restarted it would be months or much longer to get a final package ready. At various point I had hope that I could get time together to produce a final package but it is not in the cards for the forseable future.  This is not happening.

This means that the current beta build (2.0.49.0) is the latest bits and will stay the only code available for the forseable future.  This code works well for most people (> 99%).  It does not function on Windows Vista, Windows Server 2008, Windows 7 nor Windows Server 2008 R2.  As I have mentioned in other posts there's definintely some possibility of machine running beta bits of UPHClean v2.0 to crash or hang.  The best course of action in those cases is to discontinue usage of UPHClean.

Thank you for you great support on making UPHClean a success.

Robin Caron

Good news -- I'm releasing an updated beta build today.  It fixes machine hangs and crashes that could occur with build 2.0.48.0. 

The 32 bit plaform bits are here and for 64 bit platforms here.

If you find any problem with this build please email the details to uphclean@microsoft.com or post them here.

Thank you all for your patience in waiting for updated beta bits.

Robin

uphclean-setup.msi

uphclean-setup.msi

When a function uses another function to perform a simpler task it needs to make sure that once the simpler function is done work resumes on the more complex task. To make this happen it saves off where it was.  It is saved to an area of memory called the stack.  The simpler function may very well also call on other function to perform even simpler tasks.  It also needs to save off where work was before it calls on simpler function.

This is why the area of memory where this information is saved is called a stack.  Just like you would pile dishes on top of each other, the saved information is piled on top of each other.  When the simpler function is done to find out where work should resume it picks off the top of the pile.  This tells it where to go back to.  This repeats when that function is done.

Now suppose whenever an action is taken (e.g. retrieving a handle to a registry key) this stack memory is recorded.  To do this the simpler task function looks at the stack memory find out where work would resume when it is done.  What is being recorded is the address in memory where the instruction is that resumes the more complex work.  This is literally just a number between 0 and about 4 billon.  Using the earlier example this address could in a function in a printer driver that needs the page size to print on.  This process can keep going and look at when the the page size retrieval function that is done where work would resume.  This might be function that is responsible for printing.  It can keep doing that back all the way to the function that starts the application (some function in a printer spooler).  This information (a list of memory addresses) is called a call stack log or call stack for short.

Now imagine you decided that retrieving a registry key handle is causing a problem you could inspect the recorded information to determine why the action was taken.  This helps in narrowing down what causes the problem.  This is especially true today because applications are put together using 100s of thousands of functions from many vendors.  Knowing the call stack tells you who initiated the action that causes a problem.

Collection of call stacks is an option in UPHClean v1.6d enabled via the registry setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\UPHClean\Parameters\CALLSTACK_LOG to 1.  The value is a DWORD but you should find it there if UPHClean has ever been run.

The actual call stack logging is something that is not actually done by UPHClean.  You can understand why based on the explanation I gave above: UPHClean is not being called on to perform the action of opening a registry handle.  This work is actually by functions that reside in the DLL ADVAPI32.  So when you set this option what UPHClean does is set a registry setting (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\LeakTrack).  The functions in ADVAPI32 responsible for getting a registry key handle read this value.  When the value is set appropriately they collect a call stack whenever they are asked to get a registry key under the user profile hives.  Later when the registry keys are release closed it removes the discards the collected call stack information.

When UPHClean is about to process a handle that is leaked by an application for remapping or closure UPHClean checks to see if call stack logging is enabled.  If call stack logging is enabled it reads the stack information recorded by ADVAPI32.  This information is recorded as a list of memory addresses tha

It is logged in the application event log as an addition to event 1401 or 1201.  The readme has an example:

Event Type: Information
Event Source: UPHClean
Event Category: None
Event ID: 1201
Date:  10/21/2003
Time:  5:17:38 PM
User:  RCARONDOM-DC1\u1
Computer: RCARONDOM-DC1
Description:
The following handles in user profile hive RCARONDOM-DC1\u1
(S-1-5-21-3230802392-3390281410-1560515013-1307) have been closed because they
were preventing the profile from unloading successfully:
 
profleak.exe (2604)
  HKCU (0x80)
      0x77dfc200 ADVAPI32!TrackObject+0xe
      0x00412112 profleak!<no symbol>
      0x77db571b ADVAPI32!ScSvcctrlThreadA+0xe
  HKCU\Software\Policies (0x88)
      0x77dfc200 ADVAPI32!TrackObject+0xe
      0x77da1949 ADVAPI32!RegOpenKeyExW+0x10b
      0x0041350c profleak!<no symbol>
      0x00412112 profleak!<no symbol>
      0x77db571b ADVAPI32!ScSvcctrlThreadA+0xe

This this call stack data indicates that the user profile hive handle leak is caused by profleak.  Profleak is an application used to causes a user profile hive handle leak.   It is not true that in all cases the listed module/DLL listed after ADVAPI32 is the culprit.  Interpreting this information requires an experienced developer or someone who can debug.

Thank you Kevin Henriksen for this contribution.

UPHClean.ADM

UPHClean attempts to deal with that by changing the security descriptor.  This is done for access to file or directory access that result in access denied.  In the case where the file or directory is local it is likely that UPHClean will be able to change the security descriptor since it can use the take ownership right to do so.  In the remote case it is possible that UPHClean will fail to change the permissions.  So this correction UPHClean may not always succeed.

Here are relevant events that can occur:

• Event 1630: Access to %1 was granted after updating the security descriptor of the file.
  • This event indicates that UPHClean changed the security descriptor for the file/directory named %1 and was successful.  Access permissions necessary to proceed with profile work were granted.  Access to the file or directory was successful.
• Event  1631: Access to %1 failed after updating the security descriptor of the file.
  • This event indicates that UPHClean changed the security descriptor and was successful.  Even though UPHClean granted the access permissions necessary to perform the profile work the requested access was denied.  This can happen if the source of the access denied is not security descriptor permission related.  The interference could be coming from a background process (i.e. a virus scanner) or other unknown source.
• Event 1632: Security descriptor for file %1 could not be updated.  Error %2 %3.
  • This event indicates that UPHClean failed in its attempt to change the security descriptor.  %2 is replaced with the text of the error and %3 is the error number.  Access to the file or directory failed.

Note that the name logged with the event may contain an unfamiliar drive letter.  This drive letter represents the roaming profile location.  It exists only during the profile reconciliation process.

These events are logged so that you can know that UPHClean took these actions.  This is critical if auditing. 

If the user profile is reconciling properly you can ignore these.  If the profile is not reconciling properly and you are logging events 1631 or 1632 you should review the security descriptor hierarchy to insure that the permissions are as intended and allow system/administrative access.

uphclean-setup-x86-2-0-48.msi