Code 14: issue solved! (almost)

sg33 — Wed, 02 Apr 2025 19:07:38 GMT

First please stop limiting my account, requiring text message to log in, as you don't send test messages in time. please remove this feature for me I don't want it. I spent 30 minutes just trying to log in. and there is no way to contact you. please remove this feature.

Background: https://community.intel.com/t5/Wireless/Code-14-Fix-your-driver-I-already-addressed-the-issue-for-you/m-p/1678492#M59137

https://community.intel.com/t5/Wireless/Intel-R-Wi-Fi-driver-keeps-stopping-code-14-Issue-addressed/m-p/1605745#M54717

First let me explain how I addressed the issue to blocking svchot.exe will cause intel driver to stop code 14 then let me explain how I solved the issue (almost).

It started when I configured my firewall to block svchost from accessing the internet. After encountering code 14 it was always a connection was blocked for svchost and it was always port 80. (port 123 can be addressed by stopping windows time service).

looking into the events in procmon, it was always the network list service (netprofm) the last one trying to connect via port 80 (there are other services but they are not the last ones).

So allowing port 80 for svchost has fixed the issue. so I was 99.99% sure that it was the network list service (netprofm). So you would assume blocking internet for port 80 is the issue, right?

I tried to block the IP addressed that the network list service (netprofm) tried to connect to. mostly are 2 ip addresses (184.25.50.104 and184.25.50.48) and the driver was stopping code 14. so I was 100% sure that it was the network list service (netprofm).

After I started this thread and I got a reply from intel that they will not fix the issue although I addressed it exactly. So i decided to try myself as intel doesn't care about their drivers or customers, intel doesn't even care about privacy and security. that is weird.

So I always noticed there are always connections done by the svchost after the blocked connection via port 80, and it was SSDP Discovery (SSDPSRV) and it was outbound broadcast thought the ip 239.255.255.250 and port 1900. And it is always the last connections after the blocked ones via port 80, but the these outbound broadcast connections were allowed and not blocked, so I never thought it could the issue.

But I decided to test disabling SSDP Discovery (SSDPSRV) and voila the wifi driver is working even with blocking svchost from accessing the internet. And I even notice much improvement in the wifi adapter performance.

This is super weird as the outbound broadcast was allowed, but it fixed my issue for now.

Why I said "almost"? cause when the internet is gone or the router is rebooting the wifi driver will stop code 14 again. but as long the router is connected to the internet with no connections drop there are no issues. I have been working for hours via my intel wifi and no issue.

Do I expect that intel will care about my finding and fix the issue? NO, intel doesn't care. I will not looking that they will look why it is still stopping while rebooting the router. But I do hope this will help someone someday.

I still wish though that intel exports will take my finding into consideration for their driver developments. specialty this could be a huge vulnerability in the driver. as no other manufacturer is having this issue, except intel.

Re:Code 14: issue solved! (almost)

JedG_Intel — Thu, 03 Apr 2025 06:19:59 GMT

Hello sg33,

I understand that you'd like the issue you are having to be investigated and looked into and I'm sorry that you feel this way towards Intel. I will be checking this matter internally and I'll get back to you as soon as possible.

Best regards,

Jed G.

Intel Customer Support Technician

topic Re:Code 14: issue solved! (almost) in Wireless

Code 14: issue solved! (almost)

Re:Code 14: issue solved! (almost)