Microsoft Access and Outlook Integration - 48 Error in Loading DLL

A customer with a 3rd party developed Access database/application ran into this issue with some new computers. These were running 64 bit Windows 7 and 32 bit Office. The specific task was trying to open a new email in Outlook from Access.

While the error was 48 Error in loading DLL the problem had nothing to do with DLLs. It ended up being that because the computer was preloaded with Office 2016 (trial version, from Dell), when uninstalled it left some garbage behind in the registry. After running Procmon and finding out what it was trying to do, it wasn't too hard to find and fix.

The solution in the end was to delete the registry key (and subkeys):

HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}\9.6

Obviously make a backup of this key before deleting, but this did the trick for all affected computers.

PHP and imap_open with subfolders

This was tested against Exchange 2013, i assume similar environments will still apply. When using imap_open, if you're trying to access sub-folders there are a few caveats. Typically your connection string will look something like:

$imap=imap_open('{mail.server.com:143/imap/novalidate-cert}INBOX','username','password');

But there are exceptions to this:

• To connect to a subfolder of the Inbox, the end of the connection string should read INBOX.subfoldername, note the dot instead of a slash.
• To connect to a folder outside of the Inbox, the end should just be the folder name such as OtherFolder.
• To connect to a subfolder of a folder outside of the Inbox, the end should read OtherFolder/subfoldername. Note that instead of using a dot, you actually need the slash here.

cPanel high CPU usage on httpd

I had some repeated issues with multiple httpd processes sitting at 100% CPU for seemingly no good reason. A quick restart of the services would fix it for a bit, then it would come back. Running a ps axf showed that they frequently had defunct php children, but not often. For the sake of this article, let's say i was analyzing process ID 1234. I checked ls -l /proc/1234/fd and did not notice that it was any specific customer that was causing the lockups, so i knew it was not a code/site issue.

In order to dig further in, i ran strace -p 1234 to see what it was busy doing. What i saw was this:

read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
read(517, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024

over... and over... and over. All other processes were doing the same thing. Based on that, i ran ls -l /proc/1234/fd/517 and found that it was pointing to /var/cpanel/secdatadir/ip.pag. Upon closer examination, this file (presumably the mod_security paging file for IP reputation or something like that, I don't really care) was 63 GB! That could explain a lot. I stopped the httpd services, killed any stragglers, and renamed this file and ip.dir as well. After starting httpd back up again, the files got rebuilt and everything is running smoothly.