Yesterday while previewing a report I was having crashes in both the Reporting Services service (rshost) and Business Intelligence Design Studio. I was able to narrow it down to any call that involved my custom assembly code.
rshost!rshost!2d4!12/15/2011-15:41:53:: e ERROR: Generating a dump and exiting the process due to fatal runtime error.
and
Faulting application name: devenv.exe, version: 9.0.30729.1, time stamp: 0x488f2b50 Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc00000fd Fault offset: 0x0e91568b Faulting process id: 0x14bc Faulting application start time: 0x01ccbb01f553d8c9 Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe Faulting module path: unknown Report Id: a4ad4e69-26f5-11e1-a150-001c42714af2
A lookup of the exception ID referred to a stack overflow. I noticed when I moved the code from the custom assembly into the report custom code area, it would no longer crash. It was crazy.
The reason for the crashes? A recursion bug! While researching it I saw another thread where someone had the same exception caused by recursion, and this made me look into the code where I discovered recent code refactoring had introduced a new bug.
But here's the kicker.
An assembly called by rshost won't catch any StackOverflowException. So even if you wrap it in a try/catch block where you'd typically catch this in your own .NET application, it doesn't work the same way in Reporting Services. Which is a real shame: it shouldn't just crash the service. And unfortunately there's no workaround because that's part of .NET.
So we all just have to be extra careful with our custom assemblies.