Automatic Proxy Configuration Script failing on Vista
Hello everyone!
My name is Louis Shanks and I am a Senior Escalation Engineer on the IE Core team. I wanted to share with you a very interesting issue I worked on recently. The problem came in as Vista users were not able to access any external websites; however the same Vista users were able to access internal websites. So let me share a little background information on the environment before we get too far into this debug. The affected Vista users were part of the customer’s pilot program and the users had just recently installed a new corporate image. The customer was using an automatic proxy configuration script to instruct Internet Explorer which proxy it should use.
The customer has used the same PAC file in their network for years and all of the XP machines that use the same PAC file never experienced the inability to access external websites. Our first step in troubleshooting this problem was to confirm the PAC file was actually making it into the Temporary Internet Files Cache. Sure enough it was there so apparently we are not having any issues getting the PAC file. The next thing we did was to create a simplified PAC file with a few alerts. I wanted to see if the PAC file was being processed correctly.
Here is an example of what I created:
javascript:alert ("Start of our PAC File");
function FindProxyForURL(url, host)
{
javascript:alert ("Inside the function");
return "PROXY isa.proxy.server.com:80";
}
Simple enough, next we copied the PAC file up to an IIS server and configured Internet Explorer to use this PAC file:
Now it was time to test out our new PAC file. We cleared the Internet Explorer cache and attempted to go to a website like live.com. After a few seconds the request timed out and we failed to reach the website. We confirmed that the new PAC file was indeed in our temporary Internet Explorer cache, but for some reason IE didn’t process our logic. We know the PAC file is not being used because we should have seen two popup alert windows followed by the website we attempted to contact.
So we must look back at what component within Internet Explorer is responsible for processing the PAC file. That component is named JSPROXY.DLL and is located in %systemroot%\system32\. I checked and can see the file is in the proper location and is the correct version so we are left only our assumptions. One possible explanation of the failure to process the PAC file could be that JSProxy has an unknown bug, it could be that a 3rd party component is getting in the way by holding a handle open to the PAC file etc. Another reason could be that we are not even loading JSProxy.dll. After ruling out everything else using standard trouble shooting (clean booting and process explorer from sysinternals.com etc) I went with the possibility that we are not loading jsproxy.dll.
I did some testing on my machine that doesn’t experience any problems accessing external websites. I attached a debugger, researched the Internet Explorer source code and finally found that every time you change automatic configuration script’s address or file name we will call the following function.
wininet!AUTO_PROXY_LIST_ENTRY::LoadEntry
Well as it turns out this function is responsible for eventually loading JSProxy.dll. Before we go any further you will need to install the Debugging Tools for Windows the open windbg.exe and set your symbols per the steps documented here.
Now back to debugging…
I opened Internet Explorer and using Windbg I attached to this new process. Then I set a breakpoint on wininet!AUTO_PROXY_LIST_ENTRY::LoadEntry using the following command:
bp wininet!AUTO_PROXY_LIST_ENTRY::LoadEntry
Then I tell the debugger to go by using the command ‘g’ then it’s time for us to change the automatic configuration script’s setting to trigger the load of jsproxy.dll:
NOTE: Be sure to set the configuration script to the location of a valid PAC file click OK then attempt to load a new webpage like live.com.
Back over in your debugger you will see the following:
Breakpoint 0
eax=00000000 ebx=00000000 ecx=001e7220 edx=00000002 esi=001e7220 edi=001e5640
eip=46a9141d esp=0312f874 ebp=0312faf4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
WININET!AUTO_PROXY_LIST_ENTRY::LoadEntry:
46a9141d 8bff mov edi,edi
Now we haven’t attempted our load of jsproxy.dll just yet, we need to set one more breakpoint.
bp kernel32!LoadLibraryExW
NOTE: the reason I didn’t set this breakpoint first was because it would be hit all the time and that would become very annoying.
Ok now with our new breakpoint in place press ‘g’ again to let the process run. You should then break on the LoadLibraryExw.
Breakpoint 1
eax=7ffacbf8 ebx=00000000 ecx=7ffacc00 edx=001db008 esi=001e7220 edi=001e5640
eip=77e41b0c esp=0368f828 ebp=0368f838 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
kernel32!LoadLibraryExW:
77e41b0c 6a34 push 34h
If you look at the eax register you will see which dll we are about to load. In this case we are loading
0:016> du 7ffacbf8+8
7ffacc00 "c:\GDV4_F~1\jsproxy.dll"
Did you notice anything odd about the location where we are looking for jsproxy.dll? The default location is %systemroot%\system32\jsproxy.dll not C:\GDV4_F~1.
So the next thing I did was search the registry for c:\gdv4_f~1 and I found the mistake in:
HKEY_CLASSES_ROOT\AutoProxyTypes\Application/x-ns-proxy-autoconfig
As it turns out, the customer had run user state migration and something didn’t get cleaned up before they deployed the Vista build. For the scope of this problem we simply set the DllFile path listed in the above screenshot back to %systemroot%\system32\jsproxy.dll and everything started working again.
Well that’s about it. I hope this blog was interesting and informative. Until next time!
Regards,
The IE Support Team