The code execution cannot proceed because edgegdi.dll was not found

This issue happens for Windows 10, version 2004 (20H1) build:19041 related with a regression on gdi32.dll. There are lots of incorrect fix suggestions in internet for this issue that instructing rename and copy “edgemanager.dll” under system32 folder as “edgegdi.dll” and this is a BIG mistake.

Yes, this workaround immediately mitigate the problem but when you do a windows update your system most probably crash and you need to recover it. Because the sanity check of this DLL is not correct that is not suppose to be there that would crash your system while csrss.exe loading this DLL and you will face a BugCheck with 0xc000007b

This issue will be fixed with August 2021 3rd week updates, 2021-08 C , KB5005101 (not released yet while i am filling this post)
for Windows 10 2004 / 20h2 / 21h1


Advertisement

Who is listening on port 80 (http.sys ?)

In normal conditions there are several ways to check ports on a system.And there are lots of tools around like SysInternals, TCPView or good old “netstat -ano”.

But wait a minute, if we look netstat -ano;
netstat_system_process

As you can see my port 80 is reserved by “System” process (where PID=4) . Well it is easy to understand if your server installed Web Server like Apache, IIS or IISExpress to figure out who is using it but what if you don’t have any web server in your machine but who is then using port 80 ? OS itself ?

Well, I can tell you, definetly it is not “system” process itself. System process is only serving requested port for another process if your application utilize http.sys driver.
HTTP.SYS is a kernel driver so runs  under system process obviously.

Even you can use C# “HttpListener” to create small program that listen on a port by utulizing http.sys easily.
https://docs.microsoft.com/en-us/dotnet/api/system.net.httplistener?view=netframework-4.8

But is there any way to see which process actually using http.sys and bind this port ?
Yes.
Netsh http show servicestate
It will give you all bindings for registered sessions.
Registered URLs:
Server session ID: FF00000220000001
http://+:80/116B50EB-ECE2-41AC-8429-9F9E963361B7/
Server session ID: FF00000020000001
http://+:5985/WSMAN/
http://+:47001/WSMAN/
Server session ID: FF00000120000001
http://*:5357/584BBA7C-0F20-4161-BB0E-0D83BD7CA684/
Server session ID: FD0000012000001F
http://*:8855/

if you check the request queues section in results you can also see process identifiers.
Well the command results not exactly user friendly to show which PID matching which binding.But each session id order also match on printed request queue result.

Request queues:
Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs: /*first one*/
6392

Request queue name: Request queue is unnamed.
Version: 1.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs: /*Second one */
16076

Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs: /* Third one*/
23588 

Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs: /* Forth one*/
19552

If i am looking for “HTTP://*:8855/” this binding the process ID is 19552.
For my port 80. PID => 6392.

When i checked with taskmanager; it is svchost.exe. Commandline column of task manager says:
PeerDistSvc is the guy in my case.

 

 

Win10 Search from Start shows a black box

This was an issue with the online Search service.

We are aware of a temporary server-side issue causing Windows search to show a blank box. This issue has been resolved for most users and in some cases you may need to reboot your machine.
https://internal.support.services.microsoft.com/en-us/help/4540664

 

This issue was resolved at Feb 05/2020 12:00 PM PST. If you are still experiencing issues, please restart your device. In rare cases, you may need to manually end the SearchUI.exe or SearchApp.exe process via Task Manager. (To locate these processes, select CTRL + Shift + Esc then select the Details tab.)
https://docs.microsoft.com/en-us/windows/release-information/windows-message-center#387