Yes, it happens to any test I run on these particular machines. I do not have control on how OS is installed on them so I cannot correlate this problem to anything I know.
I just pushed release and debug versions of 192 though it’s probably easiest for your debugging if you just disable updates on your server (rename work/update/wptupdate.ini) while you’re debugging.
Patrick, are you able to find anything obvious in logs attached? Apparently something is being automatically deployed on my agent workstatnions one by one and all my test environment gradually becomes useless.
Sorry, I’ve been traveling (getting back tonight) and haven’t had a chance to look yet.
I just took a quick look and it looks like all the pieces are hooked up and working so it’s not clear where it is broken. I may have to send you a debug build with more tracing (the winsock hooks don’t log any data by default and the end of the test doesn’t log anything about the requests it sees).
I’ll work on the added tracing on my flight back but in the meantime does your update history show anything that might be suspicious? Browser, Antivirus, EMET or other updates?
It is really hard for me to get any information about what and when was updated. Machines I use for running wpt agents are provided to me as a courtesy of remote branches of company I work for. I would like to avoid asking them embarrassing questions
I think that debugging this problem can have added value for further development of WPT.
I just updated the 192 debug build to trace a lot more detail in the sockets path. From the looks of the traces you sent I don’t see any of the traffic that I’d normally expect to see around data we get from the raw sockets so I suspect that’s probably the source of the issue.
It might be impossible to fix if I can’t reproduce it locally though because I’ll need to figure out what is going on with the winsock calls and why they aren’t visible.
I might not be able to make any progress with it if I can’t reproduce it myself. I don’t see any of the actual socket send or recv calls (though there are some socket connect calls so it should be the correct process). If it was an IE change I’d expect to see all of the IE 11 agents having issues so I’m not really sure where to go with it.
Thanks for investigating it, Patrick. Maybe one day I will be able to identify what has been deployed to machines I use. I requested to reinstall one of them but it has not changed anything.
No, I still have this problem for some PCs. One of them was renstalled but it persists. The only workaround is to use urlBlaster but it is not compatible with IE versions greater than 9 nor any other browser.
Installing IE11 solved the problem. Probably somehow it was related to wptdriver working with IE9 or some updates installed together with IE11 removed the cause of the problem.
