Error using ole automation to send CDO Email in SQL Server 2000

I am tearing my hair out on this one. Recently (about a month or so ago) some stored procedures we have on our SQL 2000 server stopped sending emails. We have several versions of the same stored proc in different databases which all broke at the same time (I understand this is poor design but that is not what I want to discuss :))

The stored procedures use ole automation to send emails. e.g.

EXEC @resultcode = sp_OACreate 'CDO.Message', @iMsg OUT
EXEC @resultcode = sp_OASetProperty @iMsg, 'To', 'someguy@domain.com'

Now for some reason the sp_OASetProperty is failing when setting the 'To', 'From', 'Subject' or 'TextBody' properties. @iMsg is not NULL, so the create is working. Also sp_OASetProperty still works for a couple of other properties:

EXEC @resultcode = sp_OASetProperty @iMsg, 'Configuration.fields("http://schemas.microsoft.com/cdo/configuration/sendusing").Value','2'
EXEC @resultcode = sp_OASetProperty @iMsg, 'Configuration.fields("http://schemas.microsoft.com/cdo/configuration/smtpserver").Value', 'smtp.domain.com'

The result code that comes back when sp_OASetProperty fails i开发者_开发技巧s -2147220991. Using sp_OAGetErrorInfo returns the following information. Error: 0x80040201, Source: NULL, Description: Exception 0xc0000005 was generated at address...

Some other information that makes this so hard to debug:

• Only happening on Prod server, test, uat & developer machines all okay (and all using same SMTP server)
• Stored procedures have not been changed recently, they just broke one day (and we didn't notice for a while so it's hard to pinpoint what other changes were made around the time)
• I wrote a quick DotNet app and put it on the server to test email connectivity and it worked fine
• I tried replacing my local "odsole70.dll" file with the one from the server and it still worked okay so I don't believe it is a corrupt dll
• I have googled every possible combination of all the info I have put in here, but to no avail

It turns out there was some change made to the exchange server. Restarting the SQL service resolved the issue. It was probably only noticed as an issue on production because the test servers are rebooted more frequently.