MOSS - Error : Unable to find an entry point named 'OshFGetSafeHtmLAllocForManaged3' in DLL 'osafehtm.dll'

This is not a pretty error and can make you run around the house's trying to figure out what the hell is going on. [:S]
The exception tend to occurs when you try to publish changes on a site page within MOSS.
You normally see the following error stack:
“Application error when access /_layouts/AddNavigationLinkDialog.aspx, Error=Unable to find an entry point named 'OshFGetSafeHTMLAllocForManaged3' in DLL 'osafehtm.dll'. at Microsoft.SharePoint.Publishing.Fields.SafeHtmlWra[:O]pper.NativeMethods.OshFGetSafeHTMLAllocForManaged3(Byte[] htmlSourceBytes, Int32 htmlSourceBytesSize, Int32 htmlSourceCodePage, Byte** htmlReturnedBytes, Int32& htmlReturnedBytesSize, Int32 convertToDestinationCodePage, Int32 safeHtmlBehaviorFlags, String[] tagsToHandle, Int32[] tagHandlingFlags, Int32 tagHandlingCount, Int32& tagHandlingResultFlags, EditOrDropUrlsDelegate urlHandlingCallback, Boolean& isSafeHtml) at Microsoft.SharePoint.Publishing.Fields.SafeHtmlWrapper.GetSafeHtml(String stylecopStringUnsafeHtml, Int32 safeHtmlBehaviorFlags, Hashtable tagsAndFlags...”Now I have seen a lot of people using a temporary work around for this which is, to run from a command line "psconfig.exe -cmd secureresources" and then a iisreset. Well this is interesting because this seems to cure the issue for about 24 hours and then the issue seems to arise again. Oh my god! The business impact this must be having on some of the companies out there. [:O] Now the secureresources command performs SharePoint Products and Technologies resource security enforcement on the server. For example, security is enforced on files, folders, and registry keys. So why would something like this cure the issue for about 24 hours. I was amazed. [:O]
So lets look at this in a bit more detail. The stack trace shows an error with OshFGetSafeHTMLAllocForManaged3 which tells us that the dll used here is osafehtm.dll. This dll is a MOSS wrapper assembly used with the HTML controls on site pages and is used widely across the MOSS UI pages.
The OshFGetSafeHTMLAllocForManaged3 function is used mainly when there are pages that are using image or hyperlink HTML controls on a page. Also to note that the osafehtm.dll resides in the following directory in MOSS C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN\ directory. When I looked closely at the server configuration which the exception occurred I also noticed C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\BIN\ directory. And as soon as I took a peak in this directory I noticed the office 11 version of the osafehtm.dll in this directory. Bingo! Renamed the file to z_osafehtm.dll and ran a iisreset /restart the error never did occur again. [:P] Infact I renamed the 60 directory to z_60.
So here's the logic:
1. The error seems to only occur on configurations that have been upgraded from SPS2003 to MOSS.
2. With the upgrade both the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN\ and C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\BIN\ are defined paths, which means the incorrect dll can be loaded.
So why does it work for 24 hours after you run psconfig.exe securedresources and a IISReset:
I think this is because the secured resources must force 12\bin directory path to be read and loads the correct version of the osafehtm.dll assembly and the IISReset will reset all cached assemblies that are loaded in memory or cached by IIS. Within 24 hours the Application Pool will recycle itself if the default setting for the application pook are configured and at this point there are two different versions of the assembly that now can be loaded because the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\BIN\ is also a defined path and MOSS then loads the incorrect version of osafehtm.dll.