Export (0) Print
Expand All
Expand Minimize

Using the BlockRunAsInteractiveUser Fix

Published: June 11, 2010

Updated: June 11, 2010

Applies To: Windows 7, Windows Vista

This section includes information about using the BlockRunAsInteractiveUser compatibility fix, including its API-related information.

BlockRunAsInteractiveUser

BlockRunAsInteractiveUser fixes application-Setup failures. Application-Setup failures can occur when the Setup program provides alternate credentials to the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{AppID_GUID}\RunAs registry key, which mimics a Standard User or Protected Administrator, while running out-of-process COM components, which require elevation to work properly.

This compatibility fix works by intercepting and potentially blocking the program's call to the registry. If, during the interception, the fix determines a match between the registry key and the passed value, then the compatibility fix will return the ERROR_SUCCESS message. Otherwise, the fix will call the original API.

Investigating the Issue

Application-related issues that can be resolved by applying the BlockRunAsInteractiveUser fix typically appear as Setup failures, specifically when the user is running as an Interactive User. You can determine if the Setup process is failing due to the user running as an Interactive User by monitoring which handles and DLL processes have opened or loaded using a monitoring program, such as Process Explorer. If, while using Process Explorer, you determine that the application setup program is running as an Interactive User while its parent is elevated, then this could be the issue. You can inspect the call to instantiate the COM object, determine the GUID being used, and then search the registry for this GUID to determine if the RunAs registry key has been set to Interactive User.

Intercepted APIs

The following APIs are intercepted by the BlockRunAsInteractiveUser fix.

  • RegSetValueExA

  • RegSetValueExW

Fixing Your Code

Applications should be modified to allow users to run as the Interactive User only if the application’s actions would succeed for a user running as a Standard User. Additionally, the application should not assume that the interactive user has local Administrator rights, that the application can perform administrative actions without specifically requesting an elevated context, or that the administrator and the interactive user are the same user account.

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft