Handler has a bad module "WebSocketModule" in its module list - c++

Question

On 64-bit Windows 10 and IIS 10, I am trying to develop and test a native HTTP module that will act as a WebSockets handler mapping for a specific set of script files. This is all in native C++ starting with RegisterModule(). I am not using any part of ASP.NET.
When I access a URL that should invoke the handler, I receive this response:
HTTP Error 500.21 - Internal Server Error
Handler "QuadooWebSocket" has a bad module "WebSocketModule" in its module list
Detailed Error Information:
Module IIS Web Core
Notification ExecuteRequestHandler
Handler QuadooWebSocket
Error Code 0x8007000d
More Information:
IIS core does not recognize the module.
I used the IIS Manager to setup the handler mapping, and it created an entry in the applicationHost.config file.
<handlers accessPolicy="Read, Script">
<other_modules />
<add name="QuadooWebSocket" path="*.qws" verb="*" modules="WebSocketModule" scriptProcessor="E:\dev\projects\trunk\target\debug\ActiveQuadoo.dll" resourceType="File" preCondition="bitness32" />
</handlers>
Before that, I installed support for WebSockets using the "Windows Features" control panel, and it also added a line to the applicationHost.config file.
<globalModules>
<other_modules />
<add name="WebSocketModule" image="%windir%\System32\inetsrv\iiswsock.dll" />
</globalModules>
When I attach Visual Studio to w3wp.exe, none of the breakpoints in my code are resolved. RegisterModule() is not being called. DllMain() isn't even being called. My module also implements IActiveScript, and IIS does load my module for classic ASP requests.
My code is being built into a 32-bit module, and I have enable32BitAppOnWin64="true" in the applicationHost.config file. This works for the Classic ActiveScript/ASP environment, but does this setting also work when using code that is expected to be loaded via the RegisterModule() export? If that's not the issue, then are there other steps needed to enable a native HTTP module for WebSockets?
Thanks!

Answer 1

After nearly two years, I decided to spend the past few days working on this again, and it's finally working!
To answer the 32-bit question... Yes, IIS can run a 32-bit WebSockets handler on a 64-bit OS.
As to why it's working now... I did rerun APPCMD.EXE again, and I poked around in the configuration until it looked like this:
<globalModules>
...
<add name="WebSocketModule" image="%windir%\System32\inetsrv\iiswsock.dll" />
<add name="WebSocketModule32" image="%windir%\SysWOW64\inetsrv\iiswsock.dll" />
<add name="QuadooWebSocket" image="E:\dev\projects\trunk\target\debug\ActiveQuadoo.dll" />
</globalModules>
<handlers accessPolicy="Read, Script">
...
<add name="QuadooWebSocket" path="*.qws" verb="*" modules="WebSocketModule32" scriptProcessor="E:\dev\projects\trunk\target\debug\ActiveQuadoo.dll" resourceType="File" preCondition="bitness32" />
...
</handlers>
<location path="Default Web Site">
<system.webServer>
<handlers>
<remove name="QuadooWebSocket" />
<add name="QuadooWebSocket" path="*.qws" verb="*" modules="QuadooWebSocket" scriptProcessor="E:\dev\projects\trunk\target\debug\ActiveQuadoo.dll" resourceType="File" requireAccess="Script" preCondition="bitness32" />
</handlers>
</system.webServer>
</location>
One difference is that my handler is now registered with the WebSocketModule32 module.
I could end the answer there, but after my handler was finally loaded, there were a number of issues that I had to work out before it actually worked correctly. Some of what I've learned might be useful to others.
Since I'm handling WebSockets asynchronously, I needed to return RQ_NOTIFICATION_PENDING from OnExecuteRequestHandler(). Otherwise, IIS immediately closed the connection.
When switching to WebSockets, this was the order I ended up using:
Set the module context.
Set the response status to 101.
Load my script VM.
Write headers (e.g. Sec-WebSocket-Protocol).
Flush() asynchronously.
If Flush() does not complete immediately, then it will be completed with a call to OnAsyncCompletion(). If it does complete immediately, use the same code path that would be called from OnAsyncCompletion() and do the following:
Get the named context for IIS_WEBSOCKET.
Cast the context to an IWebSocketContext pointer.
Start the asynchronous reader loop.
Return RQ_NOTIFICATION_PENDING.
After receiving the closing event from ReadFragment(), I call IndicateCompletion(RQ_NOTIFICATION_FINISH_REQUEST) to notify IIS that I am done with the connection. Before I added that, IIS wasn't calling my handler's CleanupStoredContext() method.