regsvr32 didn't work for certain 64 bit dll in servercore:ltsc2019

[Bruceliu-rs]

Describe the bug I tried registering a few dll files in the servercore image and use 'reg query' to verify them, somehow one dll can found, the other can't. Both are 64 bits.

To Reproduce PS C:\shared\MFormat> regsvr32 .\MLProxy.dll /s PS C:\shared\MFormat> reg query HKLM\SOFTWARE\Classes /s /f MLProxy.dll

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{24465C14-816A-41E3-BC83-E1A04D502CF3}\InProcServer32 (Default) REG_SZ C:\shared\MFormat\MLProxy.dll

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{988CDFB8-09F0-43D4-BB86-B1613F41D940}\InprocServer32 (Default) REG_SZ C:\shared\MFormat\MLProxy.dll

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib{E028E984-C4EE-417D-A800-5C36ADD24058}\2.0\0\win64 (Default) REG_SZ C:\shared\MFormat\MLProxy.dll

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\TypeLib{E028E984-C4EE-417D-A800-5C36ADD24058}\2.0\0\win64 (Default) REG_SZ C:\shared\MFormat\MLProxy.dll

End of search: 4 match(es) found. PS C:\shared\MFormat> regsvr32 .\Medialooks.MFormats.x64.dll /s PS C:\shared\MFormat> reg query HKLM\SOFTWARE\Classes /s /f Medialooks.MFormats.x64.dll

End of search: 0 match(es) found. PS C:\shared\MFormat>

Expected behavior Reg query should have a few matches found for Medialooks.MFormats.x64.dll after registration

Configuration:

• Edition: Windows Server
  • Base Image being used: Windows Server Core
• Container engine: docker
• Container Engine version [e.g. 22] Docker version 20.10.23, build 7155243

Additional context PS C:\shared\MFormat> systeminfo

Host Name: B1EEE65D8908 OS Name: Microsoft OS Version: 10.0.17763 N/A Build 17763 OS Manufacturer: Microsoft Corporation OS Configuration: Standalone Server OS Build Type: Multiprocessor Free Registered Owner: N/A Registered Organization: N/A Product ID: 00430-00000-00000-AA735 Original Install Date: 3/12/2023, 2:39:00 AM System Boot Time: 4/4/2023, 9:00:17 AM System Manufacturer: Microsoft Corporation System Model: Virtual Machine System Type: x64-based PC Processor(s): 1 Processor(s) Installed. 01: Intel64 Family 6 Model 142 Stepping 10 GenuineIntel ~2112 Mhz BIOS Version: Microsoft Corporation Hyper-V UEFI Release v4.0, 11/1/2019 Windows Directory: C:\Windows System Directory: C:\Windows\system32 Boot Device: \Device\HarddiskVolume1 System Locale: en-us;English (United States) Input Locale: N/A Time Zone: (UTC+08:00) Kuala Lumpur, Singapore Total Physical Memory: 1,023 MB Available Physical Memory: 462 MB Virtual Memory: Max Size: 2,751 MB Virtual Memory: Available: 2,048 MB Virtual Memory: In Use: 703 MB Page File Location(s): C:\pagefile.sys Domain: WORKGROUP Logon Server: N/A Hotfix(s): 4 Hotfix(s) Installed.

                       [02]: KB4486153
                       [03]: KB5023702
                       [04]: KB5023789

Network Card(s): N/A Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be display

Thanks.

[Bruceliu-rs]

Sorry, may I have some update on this topic please?

[pbozzay]

As far as I can tell, those DLL's require a license. Are you able to suggest a different (unlicensed) DLL that I can use to repro the issue?

Barring that, here are some troubleshooting ideas:

• Confirm that this works on the host machine (I'm assuming it does, but want to make sure this has been tested). I would try omitting the /s flag to ensure no error dialogs appear.
• Dump the header information to confirm the binaries are both 64-bit.
• Run process monitor on the container host and repro the full scenario above (successful and failed registration). Filter the output to focus on any registry modifications with "Medialooks" or "MFormats" in the key name and share the output.
• In a normal cmd window (not powershell) see if "echo %ERRORLEVEL%" shows an error code after the command has run.

[Bruceliu-rs]

Thanks for the reply.

1. Yes, both works fine in my host(Windows 10).
2. Both are 64 bits. C:\Build\MFormat>dumpbin /headers ./Medialooks.MFormats.x64.dll Microsoft (R) COFF/PE Dumper Version 14.29.30146.0 Copyright (C) Microsoft Corporation. All rights reserved.

Dump of file .\Medialooks.MFormats.x64.dll

PE signature found

File Type: DLL

FILE HEADER VALUES 8664 machine (x64) 7 number of sections 5FAE66B6 time date stamp Fri Nov 13 18:57:58 2020

C:\Build\MFormat>dumpbin /headers ./MLProxy.dll Microsoft (R) COFF/PE Dumper Version 14.29.30146.0 Copyright (C) Microsoft Corporation. All rights reserved.

Dump of file .\MLProxy.dll

PE signature found

File Type: DLL

FILE HEADER VALUES 8664 machine (x64)

3. Processmon log is empty when I tried to run it in the container, while the same command works in my host. The command I used is: procmon /quiet /minimized /backingfile abc.pml and Procmon /openlog abc.pml /saveas abc.csv and the .csv just contains the following headers only. "Time of Day","Process Name","PID","Operation","Path","Result","Detail" The .pml file size is always 4096KB, while when I tested it in my host, it increased very quickly, so I think the procmon may not work in the container. Are there any way to verify it is working?
4. The result of "echo %ERRORLEVEL%" is 0.

[pbozzay]

Are you using a process isolated container? If so, process monitor on the host should pick up changes to the registry inside of the container as well. I would start it in interactive mode and filter to registry modifications that occur on paths containing "Medialooks" or "MFormats".

If you are able to share a DLL which isn't licensed, I can likely debug this on my end more quickly.

[Bruceliu-rs]

I didn't specify the isolation mode, default should be Hyper-V for my Windows 10 laptop. I uploaded a zip file including three dll files. Pls try them in your environment, thanks. Medialooks.zip

[pbozzay]

In my case, I was unable to register "Medialooks.MFormats.x64.dll" even outside of a container (likely due to missing pre-requisites installed on my machines).

In your case, I believe you have the required dependencies installed on your host (allowing the dll registration to succeed) but not in the container environment.

Based on the support page for this SDK, there is a list of dependencies that need to be present in order to register the dll's. For instance, D3DCompiler_43.dll and D3DCompiler_47.dll are required, but they are not present in the container image by default (unfortunately, I don't think that the ServerCore image supports DirectX). Using process monitor, I can see that regsvr32 searches for D3dCompiler_43.dll but cannot find it in this case and the registration fails.

I was able to make registration work in a full windows container image by doing the following.

# On the host, download the directx installer and unpack it to a folder.
# Download link: https://www.microsoft.com/en-us/download/confirmation.aspx?id=8109
mkdir C:\share
directx_Jun2010_redist.exe /Q /C /T:"C:\Share\DirectX\"

# Create a container based on the full Windows image (for DirectX support). 
# Map in the folder containing directx (unpacked) and the DLL's you would like to register.
docker run --rm -v C:\share:C:\share -it windows cmd

# Inside of the container, install directx.
C:\share\DirectX\DXSETUP.exe /SILENT

# Wait several minutes, then validate that required DLL's are present.
dir /s /b d3dcompiler_43.dll

# Register the DLL(s)
regsvr32 C:\share\Medialooks.MFormats.x64.dll /s

# Validate registration success. In my case, 5 entries were found.
reg query HKLM\SOFTWARE\Classes /s /f Medialooks.MFormats.x64.dll

If these steps are sufficient, you can create a dockerfile that automates the process.

ServerCore support In order to make this work on ServerCore images, I believe you would need DirectX to finish installing successfully. After running DXSETUP.exe /SILENT you can check C:\Windows\Logs\DirectX.log to further debug the directx installation on servercore if needed.

[Bruceliu-rs]

Thanks for the support, I try it for full windows image and servercore image, just like what you did, servercore image didn't work while full windows image works fine and I can query 5 results after registered it successfully. Are there any plan to support it for servercore image in the future?

[pbozzay]

Glad it worked for you. While I don't believe we've documented full DirectX support on servercore, it's possible that it may be operational enough for your scenario if we can get the installer to proceed. I've reached out internally to understand the log failure and will report back if I find anything. For now, since the larger image + directx install worked for you, I'd recommend that we close out the issue pending further responses on my side if applicable @fady-azmy-msft .

[Bruceliu-rs]

Ok, thanks for the support. I am OK to close it. How can I know the update from servercore, any release note page to check?

[pbozzay]

Ok, thanks for the support. I am OK to close it. How can I know the update from servercore, any release note page to check?

Are you able to try the servercore:ltsc2022 image instead? I believe that it might at least contain D3DCompiler_47.dll by default, which might be enough for your regsvr32 registration to succeed.

Alternatively, you might consider shipping the DLL's you need (e.g. the D3DX9_43.DLL, D3DX10_43.DLL, and/or D3DX11_43.DLL along with D3DCompiler_43.DLL) in your project as libraries. They are likely only being used as libraries and don't need any special installation as long as they are accessible on your PATH.

[Bruceliu-rs]

I tried the ltsc2022 image, it failed with the following error: ltsc2022: Pulling from windows/servercore docker: no matching manifest for windows/amd64 10.0.19045 in the manifest list entries. See 'docker run --help'.

and I tried the following tricks, all didn't work.

1. Switch Windows/Linux container mode;
2. Set experimental to true;
3. Untick 'Use the WSL 2 based engine';
4. Upgrade Docker desktop to latest version;

Here is my command: docker run -it -v c:\build:c:\shared mcr.microsoft.com/windows/servercore:ltsc2022

The same command with ltsc2019 tag worked fine.

[Bruceliu-rs]

Sorry, I realized ltsc2022 only works with Windows 11 or Server 2022, I don't have those environments. so can't test for now.