This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
And here we are again... 2023 and Microsoft is still neglecting to fix this issue.
On 2019, September the 27th, I wrote:
Hi everyone.
I've noticed that when Windows Defender is turned on my Classic ASP applications get very very very slow. Something like 80% slower.
We can find some information about it on the internet, about people complaining about the same thing.
The issue occurs on Windows 10 1809 / 1903 and also on Windows Server 2019 1809.
This problem does not occur on Windows Server 2016 1607.
Some say that the problem is with vbscript.dll, but even if I add this on the exclusion list the problem still occurs.
The only way to make my applications running fast again is to disable the Real Time Protection, which is obviously not what I wanted to do.
I really need Microsoft to explain what has changed and what is the best way to address this issue and solve the problem definitely.
Thanks in advance.
After more than one year wainting for a reply on a reported and confirmed issue, Microsoft answered this in the Feedback Hub:
[
Well, it happens that the issue is still happening. I've added a comment on this issue inside the Feedback Hub, but no one answered me.
So the question is: Will you fix this for once and for all?
A lot of people are waiting to turn back on their Windows Virus Protection inside their servers when they have Classic ASP pages running.
Now, this ain't possible, because you didn't fix the freaking issue.
So please, fix this ASAP guys.
Thanks
Cezar
Previous ignored posts:
2021: Classic ASP very slow when Windows Defender is turned on - Microsoft Community
2019: Classic ASP very slow when Windows Defender is turned on - Microsoft Community
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(89.60000000000001, 81%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERA%3C/text%3E%3C/svg%3E)
What version of ASP.net are you referring to?
Have you tried add your project files into the exception list?
It is not ASP.Net. I have a bunch of customers which use Classic ASP pages, and with the AV turned on those pages takes a lot of time to process and render. The only way to make them work is to turn off the AV. This is a very old issue, firstly reported back in 2018, but Microsoft never took care of the problem. And no, adding the pages to the AV exception list doesn't solve the problem.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
We have the same issue with the speed.
Yeah Jean. The first time I reported this was back in 2019. Microsoft keeps deleting my posts without caring or answering it. They should know that there are legacy code that are never gonna be converted into something modern. Windows Defender should at least treat Classic ASP code normally as it was before, and not treat it as a threat.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(35.2, 93%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJ9%3C/text%3E%3C/svg%3E)
Thank you Cezar! Your post fixed the issue for us when migrating from 2016. I've tinkered with adding Exclusions in Windows Defender to see if I could only exclude a few things, but I haven't been able to find a working combination. I'd be curious to hear if you've tried that (and had any success)? Its a shame to leave Windows Defender completely off, trying to find other solutions first if possible.
Hello Jacob, thanks for your reply. Yes, I tried A LOT of different things. For example, I tried adding specific dlls, processes, etc. to the exclusion list. None of them worked. The Classic ASP handler is located in this path: %windir%\system32\inetsrv\asp.dll That said, adding this dll to the exclusion list should solve the problem, but it does NOT. Microsoft don't fix the problem natively, nor gives us a configurable solution for the problem. They simply DON'T CARE. It's a shame Microsoft keeps on ignoring our request to fix this since we can still install ASP in IIS in Windows Server latest versions. If ASP is deprecated (as they say) and should be replaced, then they shouldn't even give us the option of installing it in the Web Server. I'm sorry, but I don't have the answer you're looking for. ☹️ I can't force my customers to upgrade their old ASP systems to ASP.Net, and still I didn't want to keep my Windows Defender turned off. Well, it is what it is. Thanks Microsoft, for letting us down once more.
Perhaps the new server will bring a solution - one can surely dream ;-) We still run over 50 classic ASP projects. I'm definitely curious to see if Microsoft will address this issue.
Hey checking back in, we found something that may be working for us. Adding an exclusion for the process w3wp.exe seems to have returned things to normal on 2 different servers so far running Windows Server 2019 Datacenter. Not a very large sample size but I thought it would be worth mentioning to see if that works for others as well.
Hey Jacob, thanks for your comment.
And nope. I remember trying that in the past and it did not work. But since you said it, I tried again, and it still did not work.
Adding w3wp.exe to the exclusion list does fix the problem, but thanks anyway!
👊
It is best to add comment and vote for this issue and this way you will inform the Visual Studio team. In case, this is an urgent issue, you may contact Microsoft Support.
