In Windows NT 4.0 DLL hell was a common occurrence. It was critical to install all apps, service packs, option packs in very specific orders to get a reliable system. When DLL conflicts occurred it was called ‘DLL HELL’ mostly because finding the root cause of such problems was a hellish experience. Today you can use application virtualization technologies such as ThinApp or App-V to eliminate these issues. However even without app virtualization on modern Windows such issues are rare and with good application design can be completely eliminated. Examples on techniques for eliminating this at application level can be found in MSDN Article “Avoiding DLL Hell” http://msdn.microsoft.com/en-us/magazine/bb985026.aspx
But if the app has a problem, you don’t have app virtualization as an option, and there is no fix from software provider available…a bit of ProcMon and file copies are probably all you need to fix it.
On launching iPhone Configuration Utility (iPCU) I was getting this error: The procedure entry point CFHTTPMessageSetHeaderFieldValue could not be located in the dynamic link library CFNetwork.dll. Tried on a few machines in my environment, all had the same error. Re-install of iTunes & iPhone Configuration utility didn’t fix the issue.
The error message displayed after entry point not found suggested re-installation of Apple Mobile Device Support.
However it was definitely installed, re-installing, updating to latest iTunes did not make the error go away.
So straight to ProcMon set a filter where
· Process Name is iPCU.exe
· Result is not SUCCESS
I then launched the iPhone configuration utility. I right clicked one entry where result was “FAST IO DISALLOWED” and selected “Exclude ‘FAST IO DISALLOWED’” This is because this gives no indication that the actual file access failed, an IRP-based operation will be tried instead. For more info on FAST IO refer to
“Disallowing a Fast I/O Operation in a Preoperation Callback Routine” http://msdn.microsoft.com/en-us/library/ff540121(VS.85).aspx
Looking here we find many attempts to load the cfNetwork.dll failing…
Now as DLLs are looked for in multiple locations (including current directory of app & directories in PATH environment variable) I checked did it succeed anywhere…To do this I set my filter to
· Path contains CFNetwork.dll
· Result is SUCCESS
· Path contains CFNetwork.dll
The result … it’s trying to load cfNetwork.dll from a directory that is not Windows included DLLs and is not Apple DLLs. Hmm. Seems strange…
A quick check of cfNetwork.dll on the system by running dir cfNetwork.dll /s from C: find two. The the DSM one is significantly smaller and does not have CFHTTPMessageSetHeaderFieldValue
Checking the path we can see why the DSM one was being used:
Copying “C:\Program Files\Common Files\Apple\Apple Application Support\CFNetwork.dll” to same directory as iPCU.exe “C:\Program Files\iPhone Configuration Utility” fixes the issue. Note we could have also copied it to C:\Windows\System32 (or C:\Windows\SysWow64 on 64-bit OS as iPCU.exe is a 32-bit EXE) However this could have introduced the risk that then DSM would access the Apple version of this DLL, instead of it’s own.
All looks good now.
Moral of the story; Don’t forget to ProcMon. And with some better application design it is possible to eliminate this problem altogether…