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.


Faulting application name: devenv.exe, version: 9.0.30729.1, time stamp: 0x488f2b50
Faulting module name: unknown, version:, 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.