Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

IIS Channel Listener Errors in Windows 10 Insider Build 14342


After installing Windows 10 Insider Preview 14342 my IIS installation appeared to be completely hosed.

Navigating to any of my local Web sites gets me the dreaded 503 Server Error:

And a string of disabled IIS Application Pools:

It turns out there are a few problems.

IIS Rewrite Module

This is getting to be a tiresome ordeal to go through every time Windows updates - the IIS rewrite module somehow gets unregistered in the Windows upgrade, and if you have sites that use that module they are going to fail.

The simple solution is to repair or reinstall the IIS Rewrite Module. For more info see my previous post.

32 Bit AppPool Failure

Even with the Rewrite module updated I was getting new errors:

I went ahead and removed the module from the root installation - but it turned out that this is a Red Herring. Although this module fails it's not the root cause.

The AspNetCore module is just a symptom, not the problem so don't bother uninstalling it regardless of the omnious error message. Read on to the real problem.

After removing the module I got yet another error with a more promising error message:

The error is:

A listener channel for protocol 'http' in worker process 'xxxx' serving application pool 'DefaultAppPool' reported a listener channel failure.

After a little bit of searching I found some old IIS Forum threads, which suggest to switch Application Pools into 64 bit mode.

And sure enough that works. When hitting Application Pools in 64 bit mode everything runs. In 32 bit - I'm back to the 503 errors.

Why am I running 32 bit

For my dev setup this should be OK even though I have all of my Application Pools currently in 32 bit. Why? 32 bit consumes less memory and in most situations actually performs slightly better (except in very high memory (multi-gig) scenarios) so I've always stuck with this. I haven't actually checked recently whether these assumptions are still true. Certainly memory will but perf - it's probably becoming less of an issue. The bigger reason is that I've run into problems with 64 bit apps in the past that worked fine in 32 bit mode but not in 64 bit. It'd be some obscure feature that wouldn't crop up until weeks later, but it's always just been more safe to run in 32 bit mode and there really wasn't a compelling reason to go to 64 bit.

Most of the apps I'm running can run in 64 bit, so for now on this local machine I can live with the 64 bit only limitation. I guess this is a good way to see what might break in 64 bit mode.

But, obviously there's a more serious problem here at the Windows level that needs to be addressed. I have no idea where to start with this. I hooked up IIS's FREB Tracing on the root site and the machine root, but I'm not getting anything. Whatever the failure is, it's never actually making it into IIS - from the looks of it the error is coming from http.sys but that's just conjecture.

So I'm curious to hear if others can duplicate this problem on their setup or whether this is an isolated or configuration based problem on my setup. For me I can't test on another machine as I don't have another machine running the previews. If you are, maybe you can try setting up a site in 32 bit mode and see if you see the same behavior.

Why?

Now the real question is why is this happening in the first place. This is definitely related to the Windows update as I was working on the same site just before Windows rudely rebooted me.

For now the 64 bit fix works for me, but it's unsettling to know that this is required to not crash in 32 bit mode. If anybody has any insight into what might be causing this to happen, I'd appreciate a note in the comments.

Posted in IIS  

The Voices of Reason


 

Sebastian Solnica
May 30, 2016

# re: IIS Channel Listener Errors in Windows 10 Insider Build 14342

Rick, I would use FREB (https://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis) to collect logs for both the 32bit and 64bit requests and later compare them. Have you done that? It's really interesting what might be causing this problem.

Rick Strahl
May 30, 2016

# re: IIS Channel Listener Errors in Windows 10 Insider Build 14342

@Sebastian - I've tried hooking up FREB tracing but I get no log file entries. I think the error occurs before IIS ever gets to process anything. From the sound of it it's WAS thats failing.

Sebastian Solnica
May 30, 2016

# re: IIS Channel Listener Errors in Windows 10 Insider Build 14342

And what about procmon? Are there any interesting errors there? I would also try reinstalling ASP.NET (aspnet_regiis.exe -i)... though it would be good to first know what exactly is the problem there.

Ian Yates
May 31, 2016

# re: IIS Channel Listener Errors in Windows 10 Insider Build 14342

I must admit I avoid 32-bit IIS and run 64-bit IIS app pools on my workstation because that's what I tend to deploy to when I install on end-user's servers (typically 2008 R2 or 2012 R2 these days). I even go out of my way to run 64-bit IIS Express when hitting F5 in VS. For some third-party libraries I use where they have native code DLLs embedded, it avoided headaches where "works on my machine" due to different bitness wasn't a good answer :)

I'll keep your post in mind if/when I run into this. Thanks for the blog - always keen to your posts.

Felipe
May 31, 2016

# re: IIS Channel Listener Errors in Windows 10 Insider Build 14342

What is the error number in Warning message from WAS?

You can see at details tab.

Are you familiar with DebugDiag? You can try to collect a dump

TK
June 01, 2016

# re: IIS Channel Listener Errors in Windows 10 Insider Build 14342

Couple of ideas:

I think that's the same (or a similar) error you see if you try to load a DLL of the wrong bitness into a process. So it might be worth confirming that the bitness preconditions are still in place in applicationhost.config, and that the DLLs are actually being loaded from the right spot (I'm thinking ProcMon).

Alternatively: 14352 is out now - assuming it's something which "just broke" on one build, it might "just work" on the next ;)
 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2017