A customer with whom I work recently encountered an error message when attempting to preview a report using SQL Server Data Tools (SSDT) in a remote session via Citrix.

The error message that was being returned was:


An error prevented the view from loading. (Microsoft Visual Studio)


An error occurred while attempting to start the report preview worker process. (Microsoft.ReportingServices.Designer)


Given that this scenario worked with previous editions of Reporting Services and BI Development Studio, the error was unexpected.  On further investigation, the same behavior and error could be reproduced by launching a Remote Desktop session in Seamless or Remote Applications Integrated Locally (RAIL) mode.

RAIL extends the RDP protocol presents a remote application running on a RAIL server as a local user application running on the client machine. This causes the remote application to appear as if it is running on the user's local computer rather than being presented in the desktop of the remote Server.

In this scenario, the behavior and the error message are both by design.

SSDT is a multi-targeted assembly that is built around the .NET 4.0 Framework. Business Intelligence Development Studio (BIDS) is built around the .NET 3.5 Framework and there are differences in the way that the .NET 4.0 Framework deals with child processes when the parent process dies. As a result, there was a deliberate decision to change the behavior of the report viewer in preview mode. This is largely because under the .NET 4.0 Code Access Security policy, executing under the current AppDomain is no longer supported, necessitating use of a sandbox. You may wish to read Brian Hartman's blog posting "Expression Evaluation in Local Mode" for a more detailed discussion of Visual Studio 2010 defaulting to the .NET 4.0 CAS policy. The net result of the change is that when a report is previewed, SSDT spawns a child process to allow previewing of the report. In the RDP using Seamless or RAIL mode, it would still be necessary for SSDT to spin up a new instance of the Reporting Services Preview Processing Host (PreviewProcessingService.exe) separate from the SSDT process. In the event that the user were to close SSDT or SSDT were to crash, it would be possible for orphaned instances of the Reporting Services Preview Processing Host application to remain in memory and continue execution after SSDT was terminated.

The change makes it cleaner to close SSDT and eliminates the possibility of orphaned child processes in the event that the SSDT environment is terminated for some reason. Had the change not been made, it would have been possible to allow orphaned child applications/processes to continue to execute, using CPU cycles and consuming server memory, until the user logged off the machine. If the user didn’t log off and rather elected to simply disconnect without logging off, any orphaned applications would have remained in memory for an indefinite period of time. In the scenario where a machine is being remotely accessed by multiple users, that could potentially mean thousands of orphaned applications would be in memory and actively executing at any given time.