[BUG] _checkPrototype function loops indefinitely when calling Invoke-WebRequest cmdlet against a docs.microsoft.com webpage

[apmpinho]

Description/Screenshot

This is related with the issue described at https://docs.microsoft.com/en-us/answers/questions/329655/powershell-invoke-webrequest-to-httpsdocsmicrosoft.html. Upon debugging the issue, it seems we loop indefinitely in a javascript function from this SDK, hence this issue.

The goal here is to verify that changes have recently been done in this area and if any IE quirk may need to be accounted for.

Steps to Reproduce

1. Open a PowerShell command line and type in the following command:

Invoke-WebRequest -Uri https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/windowsdesktop-whatsnew

2. The command may never return and you'll see powershell.exe going 100% CPU indefinitely

From the Invoke-WebRequest documentation:

The Invoke-WebRequest cmdlet sends HTTP and HTTPS requests to a web page or web service. It parses the response and returns collections of links, images, and other significant HTML elements.

This parsing is performed by using IE's mshtml.dll module, which may be part of the problem. Inspecting the CPU hogging PowerShell process, it seems we loop indefinitely in the following function:

	function _checkPrototype(classProto, thisTarget) {
        var thisProto = _getObjProto$1(thisTarget);
        while (thisProto && !_isObjectArrayOrFunctionPrototype(thisProto)) {
            if (thisProto === classProto) {
                return true;
            }
            thisProto = _getObjProto$1(thisProto);
        }
        return false;
    }

• OS/Browser: Windows 10 20H2
• SDK Version [e.g. 22]: latest stable
• How you initialized the SDK:

Expected behavior

The command returns with the DOM elements parsed. This can be observed by targeting any other URL for the Invoke-WebRequest cmdlet, not matter how complex the page may be.

Additional context

This is affecting enterprise customers that rely on this method to parse docs.microsoft.com content for certain internal processes.

[apmpinho]

Sorry, the above _checkPrototype function does not seem to be defined in this repo, but BaseCore calls dynamicProto which in turn calls into _checkPrototype. Any insight is appreciated!

[MSNev]

What version of the SDK are you using, this sounds like it's related to this issue microsoft/DynamicProto-JS#19 which was fixed March, 2020 and included in DynamicProto v0.5.2 and therefore should also be included in Application Insights v2.5.5 (Jun, 2020) or later.

Can you provide a npm list output which will identify the versions of the @microsoft/xxx packages

[apmpinho]

Thanks Nev. I'm not using the SDK directly, it's the currently in-production code at docs.microsoft.com. Can you determine the version in use from there?

I've just checked in a memory dump taken while CPU is high and indeed doc mode is 7 :( Not sure how PowerShell is calling mshtml, this page should not load in IE7 mode.

To set some context, I come from Microsoft browsers enterprise support and currently investigating this issue from the IE perspective, which lead me to this piece of javascript code. This is currently impacting a few customers/users (as you can see from the first link I paste above) and it seems there's currently no workaround for them.

[apmpinho]

With the hint on the legacy document mode in the other issue, I've added this registry value

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"powershell.exe"=dword:00002af9

And the issue no longer repros. Not sure if there's something you can do, but I guess the question is more on why PowerShell call into mshtml with docmode 7.

[MSNev]

Yes, i've just finished looking at the issue and this is actually using one of the internal SDK's which are built on-top of Application Insights (also owned by this team) and it is in fact hitting a variant of the same issue that we fixed in March 😞 .

And the docs are not including any recommended meta tags / doctype which would have avoided this issue

https://docs.microsoft.com/en-us/openspecs/ie_standards/ms-iedoco/3764531c-97c8-4bf2-bdc6-b3623738ea46?redirectedfrom=MSDN

And your workaround with the registry is effectively forcing the compatibility mode.

[MSNev]

I'm moving this issue to the dynamic proto project as that is where the issue is occurring
microsoft/DynamicProto-JS#31

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.