Run it as an administrator and turn on global capture and then all of the logging will be timestamped and displayed (you’ll need a debug WPT build).
If you actually want to step through it in a debugger then you’ll need to uncomment the message box in wpthook.cc and when the “Attach debugger” message gets displayed you’ll need to attach to the process from Visual Studio to actually debug it.
I cant seem to hit the WptHook::Init() function at all (some sample fprintf in this routine doesnt show up but does from elsewhere).
Uncommenting the messagebox in wpthook.cc, rebuild, start in MS Visual studio doesnt bring up the “attach debugger” message either.
The WPT test is setup to run with Chrome in “Native Connection” mode since I dont have dummynet installed on this Win2k12 server yet.
I’m running MS Visual Studio as Administrator and starting the prog from “Local Windows Debugger”.
On the DebugView, I do see messages coming via OutputDebugString ( Ex. Flushing DNS cache …) but nothing else. I’ve enabled
Did some more investigation. I see the following in the RegCreateKey() functions in WptDriverCore::Init(). I see (from regedit) the AppInitDLLs, LoadAppInit_DLLs are not getting set to the values 1,0 as it tries to.
Does this mean anything?
I’m running webpagetest-2.15 on Windows2k12 server (as Administrator).
In this page using http://calendar.perfplanet.com/2011/webpagetest-internals/, you talk about using (inject.cc) CreateRemoteThread() to load the dll. However, we see that in the latest code, it uses AppInitDlls approach.
Can you please clarify the difference here? I believe that the CreateRemoteThread() is more reliable.
CreateRemoteThread is actually less reliable, particularly as the browsers put in more sandbox protections. I made the change to App Init dll’s close to a year ago and it solved a LOT of issues where the agent wouldn’t inject into the browser process correctly.
If the test itself is running fine then the App Init injection is working because the test is completely driven by the injected wpthook.dll.
Are you running wptdriver.exe from the same directory as your debug wpthook.dll?
Since we’re a 32-bit process running on a 64-bit OS you might be looking at the wrong place in the registry. You need to look at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
I am running wptdriver.exe from Debug/ folder, same as wptload.dll.
You’re right; the REGKEY in the location you point out looks good.
To verify that I’m hitting the Winsock hooks as expected I added a fprintf(), OutputDebugString() inside the closesocket_Hook(), connect_Hook(), select_Hook(), but dont see the output after the test (the DbgView does show, “Pipe Logging: 10|202|Hook Active: closesocket”, …)
Also, the test itself (with IE, Chrome, Firefox) completes just fine.
What are the actual winsock hook routines that are invoked?
Best way is to just rename wptupdate.ini on the server so it doesn’t try to push the update. You can also create a directory under update with the name of the location and the server will look in there for updates instead if you only want to exclude a single location (like your dev location).