The default bug view has changed. See this FAQ.

Firefox unusable due to constant janking in wininet.dll!IsWpadEnabledForConnectedNetworks innsWindowsSystemProxySettings::GetProxyForURI

RESOLVED FIXED in mozilla16

Status

()

Core
Networking
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: roc, Unassigned)

Tracking

Trunk
mozilla16
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox16-)

Details

Just now my Firefox build was unusable due to constant hangs. I attached a debugger and did "Break All" many times as a sort of poor-man's profiling. The main thread was constantly stuck at the following stack:

 	ntdll.dll!_NtWaitForSingleObject@12()  + 0x15 bytes	
 	ntdll.dll!_NtWaitForSingleObject@12()  + 0x15 bytes	
 	kernel32.dll!_QueueUserWorkItem@12()  + 0x14 bytes	
 	kernel32.dll!_WaitForSingleObjectExImplementation@12()  + 0x43 bytes	
 	kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes	
 	wininet.dll!IsWpadEnabledForConnectedNetworks()  + 0x8d bytes	
 	wininet.dll!QueryPerConnOptions()  + 0x24f6a bytes	
 	wininet.dll!_InternetQueryOptionA@16()  + 0x37572 bytes	
 	wininet.dll!_InternetQueryOptionW@16()  + 0x94d5 bytes	
>	xul.dll!ReadInternetOptionInt(unsigned int aOption, unsigned int & aValue)  Line 90 + 0x26 bytes	C++
 	xul.dll!nsWindowsSystemProxySettings::GetProxyForURI(nsIURI * aURI, nsACString_internal & aResult)  Line 313 + 0x27 bytes	C++
 	xul.dll!nsProtocolProxyService::Resolve_Internal(nsIURI * uri, const nsProtocolInfo & info, unsigned int flags, bool * usePAC, nsIProxyInfo * * result)  Line 1255	C++
 	xul.dll!nsProtocolProxyService::Resolve(nsIURI * uri, unsigned int flags, nsIProxyInfo * * result)  Line 830	C++
 	xul.dll!nsIOService::LookupProxyInfo(nsIURI * aURI, nsIURI * aProxyURI, unsigned int aProxyFlags, nsCString * aScheme, nsIProxyInfo * * outPI)  Line 599 + 0x30 bytes	C++
 	xul.dll!nsIOService::NewChannelFromURIWithProxyFlags(nsIURI * aURI, nsIURI * aProxyURI, unsigned int aProxyFlags, nsIChannel * * result)  Line 643	C++
 	xul.dll!nsIOService::NewChannelFromURI(nsIURI * aURI, nsIChannel * * result)  Line 577	C++

Needless to say, we call NewChannelFromURI *a lot* (in my case, I saw a ton of XHR::Opens, probably from Gmail and other apps, but there were other callers too). I don't have any way to measure the distribution of pause times associated with these ReadInternetOptionInt calls, but some of them seem to be multiple seconds per call.

I haven't seen this before. There are two potential changes in my environment that could be related:
-- I've just started using the wired network at the hotel. Maybe this network, or something on it, is making IsWpadEnabledForConnectedNetworks super slow? However, when I started my laptop on this network for the first time this morning, things were OK.
-- However, soon after that I finished installing some Windows security updates and rebooted to let those updates take effect. I only saw this problem after those updates took effect. These are the updates I installed:
Security Update for Windows 7 for x64-based Systems (KB2698365)
Cumulative Security Update for Internet Explorer 9 for Windows 7 for x64-based Systems (KB2719177)
Windows Malicious Software Removal Tool x64 - July 2012 (KB890830)
Security Update for Windows 7 for x64-based Systems (KB2655992)
Security Update for Windows 7 for x64-based Systems (KB2691442)
Security Update for Windows 7 for x64-based Systems (KB2719985)
Security Update for Windows 7 for x64-based Systems (KB2718523)
Definition Update for Microsoft Security Essentials - KB2310138 (Definition 1.129.1744.0)

Kyle says this may be related to bug 766280. This is an ultra-critical bug; it will force users to use another browser if they can find one that isn't affected by this bug (I didn't check).
See also https://bugzilla.mozilla.org/show_bug.cgi?id=766280#c3

I only managed to catch it in the debugger once.
Blocks: 563169
status-firefox16: --- → affected
tracking-firefox16: --- → ?
>	xul.dll!ReadInternetOptionInt(unsigned int aOption, unsigned int & aValue)  Line 90 + 0x26 bytes	C++
This function was renamed by bug 771115. Is this bug reproducible on the latest build?
I think this was fixed by bug 771115.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Depends on: 771115
Resolution: --- → FIXED

Comment 4

5 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #3)
> I think this was fixed by bug 771115.

Found in 16, fixed in 16.
tracking-firefox16: ? → -

Updated

5 years ago
status-firefox16: affected → ---
Target Milestone: --- → mozilla16
You need to log in before you can comment on or make changes to this bug.