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


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

Anjular.js fragment identifier “#” hash issue with SharePoint 2019 Modern UI

OnPrem SharePoint 2019, Modern UI, Horizontal Navigation Bar trimming special characters in our case “#” (Hash) in query strings for link entries which breaks 3rd Party Angular.js navigation.
like: http://www.contoso.com/home.aspx/?#/banner/yellow

(Btw:This issue is not present on SharePoint Online)

This issue only happens with SharePoint 2019 Modern UI and if you store your links with Vertical or Horizontal Navigation OOB control.

The reason is OOB Modern UI Navigation components trims any fancy character including hashes (#) where it is required for your angular.js custom solution navigation or routing purpose.

For resolution; you may try following workarounds:

There are several articles in related Angular design and how it may change this behavior.

There are always some issues we are expecting integrating 3rd party tools with SharePoint. We are trying to support as much as possible 3rd party JS library usage with SharePoint like Angular.js, but we don’t have support for Angular.js itself. It is an open source project that we cannot help much to removing “#” on Angular.js for angular navigation. This is out of scope for Microsft Support.

Luckily, Microsoft SharePoint product group fixed that behaviour and the resolution has been addressed with November CU 2019 for SharePoint Server 2019.

November 2019 CU for SharePoint Server 2019 is available for download

 

 

About future of the Content Deployment feature for SharePoint 2019

This article is about future of the “Content Deployment” functionality in SharePoint.
SharePoint production team is not improving the feature till SharePoint 2013 and they will not invest “Content Deployment” in newer SharePoint Builds.
So you should be consider to find an alternative on it.

Feature itself It is not depreciated but it will be present in SharePoint “AS IS” for backward compatibility mode and if any new feature implemented in SharePoint 2019 if it is not convenient or breaks content deployment, it will not going to be adjust/fixed.
Another meaning; SharePoint engineering team will not consider the effect for any new features on Content Deployment.
If you want to continue to use “Content Deployment” Either you should disable the newly implemented features in SharePoint 2019 (Where it may not possible some scenarios) or you need to switch an alternative (Mostly 3rd party products or manual operations)

Our official statement on this issue: Content deployment was announced as NOT recommended since SharePoint 2013 and also this statement valid for higher builds, with limitations and alternatives called out here https://blogs.technet.microsoft.com/tothesharepoint/2013/07/15/changes-to-content-deployment-in-sharepoint-server-2013
While it has not been formally deprecated, it has a limited degree of support, including not supporting the deployment of many features.