When it comes to IIS extensibility, possibly ASP.NET is the easiest and most versatile choice. In fact, starting with IIS 7, the integrated pipeline allows custom managed code that implements System.Web.IHttpModule to be registered for all the IIS pipeline events. This means .NET code can be used to extend all sorts of applications, including those relying on native handlers, at the only cost of loading the .NET runtime within the IIS worker process.
However, there may well be situations where .NET is not the best option, let alone when it is just not an option at all. In such cases IIS also offers native pipeline extensibility solutions. The CGlobalModule and CHttpModule classes are great examples of how developers can implement their own classes and register them to the IIS pipeline notification events.
Compared to managed ones, native modules can be more articulated to develop. Still the design principles behind them are similar. Native modules can register to multiple pipeline notification events, which essentially means different functions can be invoked at different stages of the request lifecycle.
Thus, data persistence across multiple executions is key in building stateful modules. The IHttpStoredContext interface is designed to address this requirement.
As memory management in native code is more articulated and http modules and their stored context classes can access several resources shared with other parties (i.e. the other pipeline modules), a proper knowledge and usage of the APIs is paramount is preventing cumbersome issues like the following.
Issue
The problem is essentially IIS 10 not logging any request for a site where a native module is installed.
To add more context, let the module inherit from CHttpModule and implement IHttpStoredContext. Once installed the module works just fine and it is able to carry out all its tasks. Oddly enough, logs are also working for all the other sites which don’t have the module installed.
To complicate the situation even more, let the very same module (literally the same .dll file) be installed on a IIS 8.5 server with no logging issues at all.
At a first glance, such an issue would seem to relate to a regression in IIS 10. However, no relevant code changes between IIS 8.5 and 10 were made as far as native extensibility and logging are concerned.
Cause
Extensive and in-depth troubleshooting reveals the underlying issue is the custom module overwrites the HttpLoggingModule own stored context. How could it be?
The module is, among other things, registering for multiple pipeline events. It is also setting a custom context to persist data throughout the whole request lifecycle.
The module is registering its context with a code similar to:
{
CStoredContext* myCtx = new CStoredContext;
myCtx->Initialize();
…
ctxContainer->SetModuleContext((IHttpStoredContext*)myCtx, NULL);
}
It is key to note the SetModuleContext API expects the module registration ID as second parameter. IIS assigns a unique ID to each module when it first registers:
static HRESULT RegisterGlobalModule
(
DWORD dwServerVersion,
IHttpModuleRegistrationInfo* pModuleInfo,
IHttpServer* pGlobalInfo
){…}
The module ID is actually more than just an identifier. Actually it is the index of the module registration within the registration array managed by IIS (the data structure is actually a more articulated linked list, but here we can safely assume it works exactly like an array).
You may have noticed already that in the code above NULL is passed to SetModuleContext as second parameter. NULL is casted to 0 at runtime (HTTP_MODULE_ID defaults to 0) which means IIS will interpret the module registration to be in the first slot. Therefore, when writing to its own stored context, the module would overwrite any data previously set by other modules.
This is exactly the situation here: in fact the http logging module is registering as first in position 0. Then, whenever the other native module runs, it overwrites the previously registered context, preventing the actual log from being dispatched to the logging service for writing.
Resolution
This is a typical situation where a proper usage of the API can lead to a quick and immediate problem resolution. Specifically, all it takes is to properly pass the actual module registration id to SetModuleContext. A way to do this right is simply by storing the module id in a global variable:
protected:
DummyGlobalModule(HTTP_MODULE_ID moduleId)
{
m_moduleId = moduleId;
}
private:
HTTP_MODULE_ID m_moduleId;
Then, populate it when the module is registered:
static HRESULT RegisterGlobalModule
(
DWORD dwServerVersion,
IHttpModuleRegistrationInfo* pModuleInfo,
IHttpServer* pGlobalInfo
)
{
if (NULL == pModuleInfo)
{
return E_INVALIDARG;
}
HTTP_MODULE_ID moduleId = pModuleInfo->GetId();
if (NULL == moduleId)
{
return E_INVALIDARG;
}
DummyGlobalModule* dummyModule = new DummyGlobalModule(moduleId);
Eventually call SetModuleContext like this:
{
CStoredContext* myCtx = new CStoredContext;
myCtx->Initialize();
…
ctxContainer->SetModuleContext((IHttpStoredContext*)myCtx, m_moduleId);
}
For those who are wondering why in IIS 8.5 this issue does not occur, the answer is again linked to the way the API works. In fact, the module registration order is opportunistically set at runtime and depends on the module registration order.
Indeed, in IIS 10 the http logging module was shifted earlier in the modules list. It is high likely in IIS 8.5 the native module is registering before the http logging module, hence getting assigned to the registration slot 0. This is what indirectly validates using NULL as module ID when calling SetModuleContext and makes everything work seamlessly, despite the API usage is incorrect.
