BUG: binary module loading fails silently on Fall Creators update on some machines
occurs in PS 5.1 on Windows 10, Fall Creators update
First observed with SqlServer module 21.0.17199
Also occurs with PsWindowsUpdate v18.104.22.168 , SqlServer 21.0.17224
Pretty much what it says - with either autoload or Import-Module, the module loads with no complaints but the cmdlets aren't there. The assemblies _do_ get loaded into the appdomain. I found no obvious clues poking around with ProcMon and Trace-Command (obvious to me, anyway). Happens on some machines, not others. Reported by 3 users (that I know of), in each case after updating to the Fall Creators update. If you have any debugging hints, they'd be appreciated.
Originally reported here: https://www.powershellgallery.com/packages/SqlServer/21.0.17199#lf-content=193467826:746604807
PsWindowsUpdate issue reported here: https://www.powershellgallery.com/packages/SqlServer/21.0.17199#lf-content=193467826:755426344
Possibly related to: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11088816-cannot-build-a-binary-module-referencing-3-0-sma-d ??
I guess it's back to bug status. I've included below the tree of references to related posts and articles (based on my research, as of today, may not be exhaustive, etc).
Perhaps one of the solutions there will work for you. If not, perhaps you'll find one and add to the collective wisdom. A lot of time has been eaten by this and related issues over the years. Microsoft - a diagnostic wizard perhaps?
People have thrown the fusion logger, procmon and trace-command at this problem, generally to no avail. My best guess (posted elsewhere) is that the crux of the problem lies in PowerShell's binary module loading code, which is probably failing to do an error check at some point where it really ought to. But that's just a WAG.
I don't see a lot of evidence of people being able to reproduce this problem. It either happens to you or does not. It has failed to fail on machines I had that (I thought) were configured identically to machines that were failing (I'm guessing there was some subtle difference in precisely what versions of things were installed, when and in what order).
(I'm amused that my earlier reference to DLL 7734 was robot-censored by UserVoice. This clearly IS an example of DLL 7734 https://en.wikipedia.org/wiki/Calculator_spelling#English )
Paul Scivetti commented
Is there any actual work-around for this? Tried the registry entries noted below - nada. I'm trying to get the SqlServer Powershell module installed, but after the install, still can't see any of the cmdlets. Very frustrating.
Workaround (fix?) works for me (the original poster). @pwesten - I'm interested in how you made the connection from an ASP.Net Core issue to this one.
Also interesting - If you chase all the links that people have kindly left behind in their comments, it takes you all the way back to August of 2012: https://stackoverflow.com/questions/12060460/using-powershell-2-as-the-default-version-on-windows-8. I guess even Fusion won't keep you completely out of DLL ****.
Is there some way to downgrade this from BUG to bug-with-known-workaround?
riegelj posted a fix on https://github.com/aspnet/Tooling/issues/755 that worked for me:
adding this registry entry fixed my problem. Thanks @n777ty for figuring this out.
Windows Registry Editor Version 5.00
hope you'll find this useful
same problem here
J Case commented
I have the same problem on Windows 10, Fall Creators update