Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CLR Causing Server Reboot?

7 views
Skip to first unread message

BH

unread,
Feb 16, 2010, 1:54:30 PM2/16/10
to
I'm running a CLR assembly that was designed to resize images within SQL
Server. The assembly is "safe" but uses System.Drawing which is "unsafe".
When provided with the PK of the datarow, the CLR assembly will retrieve the
image from the database, resize it, and update the image in the database
with the newly resized version.

In order to do a one-time resize of all images, the execution of this CLR
assembly has been put inside of a T-SQL loop - each image is resized in a
standalone execution of the assembly. To process 450,000+ images took 26
hours and reduced the space used by images from 60Gb to 15Gb.
Unfortunately, the server threw a memory exception and restarted about 20
minutes after the process finished.

We had been monitoring memory (we'd seen this problem before) and nothing
appeared out of the ordinary during the entire time the process was running.
At all times during the execution of the resizer (and ever since the
reboot), the max contiguous free memory size was 157,412 Kb. However, for
the 20 minutes between the end of the resize process and the server
shutdown, this memory dropped to 91,840 Kb. Not sure if its related, but it
was strange to see it drop for those 20 minutes.

Message from Event Viewer:
SQL Server is terminating because of fatal exception e0455858. This error
may be caused by an unhandled Win32 or C++ exception, or by an access
violation encountered during exception handling. Check the SQL error log for
any related stack dumps or messages. This exception forces SQL Server to
shutdown. To recover from this error, restart the server (unless SQLAgent is
configured to auto restart).

We're assuming that it was this image resizer that caused the shutdown but
scratching our heads over why it would happen once the final image was
processed. The images were processed in order from largest to smallest
(largest being 7.5 Mb). I could even see if the looping was done within the
CLR assembly and a single execution of it had been running for 26 hours but
that's not the case here.

Any suggestions about this exception would be greatly appreciated. I can't
find any useful references to it anywhere.


Hugo Kornelis

unread,
Feb 28, 2010, 3:59:12 PM2/28/10
to
On Tue, 16 Feb 2010 13:54:30 -0500, BH wrote:

(snip)


>Any suggestions about this exception would be greatly appreciated. I can't
>find any useful references to it anywhere.

Hi BH,

Since there is no response yet, I'd say that you are not alone in being
at a loss to find an explanation.

If the shutdown had happened during the CLR execution, I'd immediately
suggest a detailed inspection of the assembly. But if the last execution
had already completed, I cannot see how the assembly could possibly
cause this.

Are you sure there were no other connections executing CLR code at the
time of the unexpected shutdown?

Also, I am intrigued by this part of your post:

> The assembly is "safe" but uses System.Drawing which is "unsafe".

As far as I know, an assembly that uses "unsafe" components can never be
catalogued as "safe". Could you elaborate on this?


Even though I offer a few suggestions for further investigation, I have
to admit that it's mostly clutching straws and shooting in the dark. If
you still have the logs and other relevant information, I'd suggest
opening a case with Microsoft Support. If it's a bug (and a memory
exception of the SQL Server process almost always is) and it's not
already documented and/or fixed in a service pack, you won't be charged
for the support call (or you get the charges reimbursed; I'm not quite
sure what the exact procedure is nowadays).

If you ever find the cause, please do let us know!

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

0 new messages