A client enquiry brought out some interesting discrepancies in the way in which the Universal Driver Heavy (UDH) communicates the fact that it has stopped. The client in question wanted to be able to monitor the UDH to create alerts when it flipped into journaling mode so that corrective action could be taken.

Initially they thought that it would be enough to check the registry key value "MirrorInBackup" but they quickly ascertained that whilst this could be relied upon to show whether the UDH had been put manually into journaling mode, the registry key was not updated when the UDH flipped into journaling mode because of some failure.

Revelation very kindly provided us with the workaround - which was to check for the existence of journal files - if they exist then we're journaling regardless of what the registry value may say! As there are a variety of journal files this isn't a completely straightforward task but the required logic can be represented as follows :-



So with this scenario we can establish whether it is journaling AND whether the secondary server is back on line and being replayed to. Both scenarios mean that journaling is taking place but only one is potentially an error condition.

We recently undertook a consultancy exercise on a client's site, where, to cut a long story short, the system started failing with C0000005 exception errors. This was a new development as the system had been stable for some time beforehand so we were at a loss to explain why.

Every other time we'd encountered this error it had been shown to be DEP related so we confidently asserted that this must be the case now. We suggested disabling DEP for OI and rebooting the server. This suggestion was not met with universal acclaim as this was a UDH site and the client wanted 100% up time. Reluctantly a window was scheduled to log everyone out of the system and the modifications were made and the server was cycled...

And the system kept failing with C0000005 exception errors.

At our wit's end we again resorted to installing an oeprofile.log to see what was going on at the time of the crash.
 
Now a quick caveat - the site was not at 9.4 so the SQL Bond was not as robust as it is now. Examining the log showed that a program used with the bond had become recursive. When this happens the program just keeps getting loaded onto the stack along with the creation of new variable pools until something breaks. 

In this case it was Windows GPFing the engine with C0000005 exception errors.

So next time you see a crash with C0000005 exception errors, don't necessarily assume that it has to be DEP - it could be you!