Trust Not Granted When Running WPF In IE
This is a post from the archives. This was one of my most popular posts for a long time. A lot of people experienced a lot of pain with WPF. Hopefully this helped them.
See more archived posts in the archives.
Update 7/10/2013
Since this is one of my most popular articles, I'll summarize.
- Ensure the certs used to sign the WPF are present on the client's machine
- Run the WPF XBAP permissions tool to fix any registry errors
- PROCMON is a great tool for tracking down issues. It pointed us to our problematic key: HKCU\Software\Policies\Microsoft
/Update
At work, we were getting a few users who were unable to run our deployed WPF application. When running under https, a Windows Presentation Foundation Host error would occur with the following message:
Trust Not Granted
The application cannot be deployed because it is not trusted and possibly unsafe.
Recorded in the Error Log were the following messages:
System.Deployment.Application.TrustNotGrantedException (Unknown subtype)
and
User has refused to grant required permissions to the application.
We had triple checked that the certs were installed on the client's machine and still stumped why we were getting the error.
A blog entry on MSDN suggested modifying the CASPOL. After modifying the CASPOL by giving the site FullTrust, the WPF would run in the browser, but it still wasn't working 100%. Our application makes several web service calls, and the application was erroring when making those calls.
Running ProcMon and filtering for ACCESS DENIED showed that PresentationHost.exe was denied several spots in the registry.
Running the WPF XBAP Permission Error Tool fixed some of the ACCESS DENIED errors. For others, the user account had to explicitly have read permission to the registry keys and subkeys. It doesn't matter if the user account is in the Administrators group.
In our case, the problematic key was
HKCU\Software\Policies\Microsoft
Without explicit read access, PresentationHost.exe couldn't determine what Security Zone the XBAP was running under in IE. This in turn caused the WPF to execute under the Nothing Permissions Set.
Once the user account had explicit read permissions to the registry keys, our WPF application ran with no issues.