FF and Chrome stuck at blank2.html


I don’t get my private node to work. Getting frustrated :dodgy:
Does somebody have a hint? :huh:


  • windows 7 enterprise 64 bits
  • dummynet 64 bits (from the 2.19 tree)
  • chrome_54.exe via chrome.dat installed
  • firefox_50.exe via firefox.dat installed
  • update.zip version 386 installed
  • wptupdate.zip version 334 installed
  • wpt server version 2.18 installed


Do you have an antivirus or other software that may be blocking access? It looks like the code injection isn’t working for Firefox and Chrome which rely on using an AppInit dll (IE uses different injection which is why it is working).

Not that I know of… Are there any ‘standard’ settings of Windows 7 which could be able to prevent this? I started from a scratch windows system, following these instructions: https://sites.google.com/a/webpagetest.org/docs/private-instances

:-/ Not that I’m aware of. As long as the agent is running with admin permissions (and I don’t think it will launch without them) it should be writing the necessary reg keys to enable app-init dll’s even if they were disabled.

Just a sanity check, is wptdriver.exe still 334 on the test machine even after the install? If the server has a different version in the /work/update directory then the agent will download that and use it instead, even if it is an older version (though in that case it usually isn’t stuck on “connecting”.

And now 100% sure it is running as administrator:


Very strange…

  • I set AppInit_DLLs manually to C:\wpt\wptload.dll
  • Start a test
  • while it is stuck on blank2.html (still trying to connect) refresh(F5) regedit content
  • AppInit_DLLs is empty!


Started a complete new installation and ended with the same problem :@

I think it is in the writing of the registry in the WptDriverCore::PreTest().
To be sure, is it possible to build a debug version with some writes to a logfile?

Here is a debug build of 334: www.webpagetest.org/releases/wptdriver334d.zip

You’ll need debugview: https://technet.microsoft.com/en-us/sysinternals/debugview.aspx

Start debugview and set it to capture win32 (I usually run as administrator and enable global capture but that might just be force of habit).

The agent should spew a bunch of stuff to the logs.

As far as the AppInit reg key goes, it should write to it just before launching the browser and once it detects that the hook dll has loaded into the browser it removes the key so it hooks as few processes as possible.

Thanks! Created a log. I don’t see any problems. Do you?


Looks like the extension keeps connecting and requesting /blank2.html (which it needs to successfully load before continuing). There are some IPv6 warning messages but that shouldn’t be an issue. For sanity, can you try disabling IPv6 on the network interface?

It should show HTTP Request: /blank2.html and then shortly after make a request for /task (the extension talks to wpthook.dll through a local web server).

I’ll look through the extension code and see if I can find any reason why it would keep looping on /blank2.html with /viewport.js in there as well.

Good news is that the code injection is working fine so it’s more something going wrong with the extension for some reason.

Thanks for helping…
Until the weekend I won’t be able to experiment; at a conference.

Hi Patrick,

Where you able to find something? Is there something I can do?