[Bug]

[SavAlexander]

GhostDeck version

1.24.0

MSI laptop model

MSI Delta 15 A5EFK

Windows version

Windows 11 25H2

BIOS version

E15CKAMS.10C

EC firmware version

15CKEMS1.108

MSI Center status

Installed and running

Problem description

I keep getting the following error every time I try to capture EC:

Couldn't read the EC (is the MSI WMI interface available?)
Details: Unsupported

The EC Firmware field is just blank (shown as "-").

Steps to reproduce

1. Use MSI Delta 15 A5EFK
2. Open GhostDeck
3. Model->Verify my model->Capture->Error

Expected behavior

no errors

Actual behavior

error:
Couldn't read the EC (is the MSI WMI interface available?)
Details: Unsupported

Logs and screenshots

No response

Submission checklist

• I searched existing issues and discussions for the same problem.
• I removed credentials, personal information, and sensitive data.
• I have not attached installers, executables, or archives containing compiled binaries.

[wygodad]

Thanks for the precise report @SavAlexander - the detail that matters is buried in that one word, "Unsupported".

What it means. That is the WMI status WBEM_E_NOT_SUPPORTED. GhostDeck reads the EC through MSI's own WMI class MSI_ACPI and its Get_Data / Get_EC methods. The error says the class is there, but the method call is refused as not supported - which is also why the EC firmware field stays empty (that field is filled by Get_EC). So this is not the model map being wrong; it looks like this firmware simply does not expose the methods GhostDeck needs. Nothing in the app's settings can work around that.

What I cannot tell yet, and where you could help: whether the methods are missing entirely on your machine, or named differently. Two read-only PowerShell commands answer it - please run them in an admin PowerShell and paste the output:

Get-CimClass -Namespace root\wmi -ClassName MSI_ACPI | Select-Object -ExpandProperty CimClassMethods

Get-CimClass -Namespace root\wmi | Where-Object CimClassName -like "*MSI*" | Select-Object CimClassName

The first lists the methods your firmware actually offers (I expect Get_Data / Set_Data to be absent or different); the second shows whether MSI exposes another interface on your board that could be used instead.

Fixed regardless, in the next release: instead of the bare "Details: Unsupported", the wizard will say plainly that the laptop's firmware does not implement MSI's EC WMI methods and that this is a firmware limitation, not a settings problem. Access-denied and interface-missing cases get their own wording too.

One more question: does MSI Center itself control the fans / battery limit correctly on your Delta 15? If it does, the interface exists in some form and your output above should reveal it.

[SavAlexander]

MSI Center itself works about as well as it possibly can. Depending on the version, one mode or another is always broken.
For example, in version 2.0.71.0, the custom fan curves work, but Cooler Boost doesn't.
1_response.txt
2_response.txt

[wygodad]

I was wrong, and your output shows it plainly - thank you for running them.

Get_Data, Set_Data and Get_EC are all present in MSI_ACPI on your Delta 15 (40 methods, the standard MSI set). So the interface is not missing, and the "Unsupported" comes from somewhere else - the ACPI code behind the method refusing that particular call on this board. Scratch my firmware-limitation explanation.

Two candidates I can actually check with your help, both cheap:

1. Which instance we talk to. GhostDeck takes the first MSI_ACPI instance it finds. If your machine exposes more than one, we may be calling the wrong one:

Get-CimInstance -Namespace root\wmi -ClassName MSI_ACPI | Select-Object InstanceName, __PATH

2. The buffer class the method expects. We pass a 32-byte Package_32 as the Data argument (that is what the MSI boards I know use). If your firmware declares a different buffer:

(Get-CimClass -Namespace root\wmi -ClassName MSI_ACPI).CimClassMethods["Get_Data"].Parameters |
    Select-Object Name, CimType, ReferenceClassName

Get-CimClass -Namespace root\wmi | Where-Object CimClassName -like "Package_*" | Select-Object CimClassName

If it turns out your board wants a different package size or a different instance, that is a fix on my side, not a limitation on yours - and one that likely helps every Delta/Alpha-class board.

One aside that may be useful to you meanwhile: you mentioned MSI Center 2.0.71.0 gives you working fan curves but a dead Cooler Boost. Cooler Boost is a single bit (0x98 bit 7) that GhostDeck can flip directly - but only once we get the EC path working on your machine, so let us finish this first.

[SavAlexander]

I ran the following command:
Get-CimInstance -Namespace root\wmi -ClassName MSI_ACPI | Select-Object InstanceName, __PATH
and got this error:
Get-CimInstance: The requested operation is not supported.

(Get-CimClass -Namespace root\wmi -ClassName MSI_ACPI).CimClassMethods["Get_Data"].Parameters | Select-Object Name, CimType, ReferenceClassName

Name CimType ReferenceClassName

---

Data Instance

Get-CimClass -Namespace root\wmi | Where-Object CimClassName -like "Package_*" | Select-Object CimClassName

CimClassName

Package_64
Package_10
Package_1
Package_32

[wygodad]

That output moves us a big step forward - and it clears the EC method call entirely.

Get-CimInstance ... MSI_ACPI failing with "The requested operation is not supported" means even listing the instances of the class fails, before any EC method is involved. GhostDeck's very first step is exactly such a listing (SELECT * FROM MSI_ACPI) - that is why everything after it dies with the same word, and why the firmware field is blank. Meanwhile the class definition is present (your first output) and Package_32 exists on your machine (your third output), so the pieces are all there; what is broken is the binding between the WMI class and the ACPI device behind it.

Three short checks, if you have another minute - the second one is a potential fix on my side:

1. The ACPI-WMI device that backs all the MSI_ classes:*

Get-PnpDevice | Where-Object InstanceId -like "ACPI\PNP0C14*" | Format-List InstanceId, Status, FriendlyName

Status should say OK; anything else points at the mapper device itself.

2. Direct binding by path, skipping the enumeration that fails:

[wmi]'\.\root\wmi:MSI_ACPI.InstanceName="ACPI\PNP0C14\0_0"'

If this prints an object instead of an error, GhostDeck can fall back to binding this way whenever the normal listing fails - that would likely make your Delta 15 work without you changing anything.

3. Scope - is it only MSI_ACPI or every MSI class:

Get-CimInstance -Namespace root\wmi -ClassName MSI_CPU | Select-Object -First 1

One more question: did GhostDeck (or an EC tool in general) ever work on this machine on an earlier Windows build? You are on 25H2, which is fresh - if this broke with the OS update, that narrows it a lot.

Context that fits so far: MSI Center 2.0.71.0 still manages your fan curves, so MSI's own software reaches the EC by some path - consistent with the interface being alive but the standard enumeration being refused on this board/OS combination.

[SavAlexander]

Get-PnpDevice | Where-Object InstanceId -like "ACPI\PNP0C14*" | Format-List InstanceId, Status, FriendlyName

InstanceId : ACPI\PNP0C14\0
Status : OK
FriendlyName : Microsoft Windows Management Interface for ACPI

InstanceId : ACPI\PNP0C14\AOD
Status : OK
FriendlyName : Microsoft Windows Management Interface for ACPI

I also tried:

[wmi]'\.\root\wmi:MSI_ACPI.InstanceName="ACPI\PNP0C14\0_0"'

and got the following error:

InvalidArgument: Cannot convert value "\.\root\wmi:MSI_ACPI.InstanceName="ACPI\PNP0C14\0_0"" to type "System.Management.ManagementObject". Error: "The parameter is incorrect."

Get-CimInstance -Namespace root\wmi -ClassName MSI_CPU | Select-Object -First 1

Active CPU InstanceName PSComputerName

---

True 13 ACPI\PNP0C14\0_0

The problems with MSI Center started back on Windows 10 when the 2.0.70.0 update was released.

That version significantly changed AI Mode. The fans stopped ramping up beyond roughly 4000 RPM, and if I remember correctly, Cooler Boost also stopped working.

I also spent quite a bit of time on Windows 10 trying to figure out why GhostDeck couldn't create a capture. I tested several versions of MSI Center (2.0.48.0, 2.0.62.0, and 2.0.70.0) and tried disabling various MSI Center processes, thinking one of them might have exclusive access to the EC.

In the end, I came to the conclusion that GhostDeck simply doesn't know how to work with the EC version on my laptop yet.

Installing Windows 11 didn't change anything.

[wygodad]

Thank you - this round settles a lot. Let me be explicit about what is now fact and what is still hypothesis, so it is clear why I ask for each command.

Established facts (from your outputs):

• Both ACPI-WMI mapper devices are healthy (ACPI\PNP0C14\0 and \AOD - the second one is AMD-specific and expected on this board).
• The mapper and MSI's classes work: MSI_CPU enumerates normally and even shows the exact instance name format on your machine: ACPI\PNP0C14\0_0. So this is not a dead WMI layer - it is specifically MSI_ACPI that refuses to be listed.
• The direct-bind test from my last comment never actually ran: that "Cannot convert value... The parameter is incorrect" is PowerShell failing to parse the path string (backslash escaping - my fault for a fragile one-liner), not WMI answering anything. So that test is inconclusive, not failed.
• Timeline: this never worked on your machine, on Windows 10 or 11, across MSI Center 2.0.48-2.0.71. So the OS is not the variable, and I withdraw the 25H2 angle entirely (it also works fine on 25H2 on other boards).

Current hypothesis - unverified: your firmware's MSI_ACPI does not support the "list instances" operation, but may still allow binding directly to the instance by its exact path - which we now know thanks to the MSI_CPU output. The only way to verify it is the corrected command below.

$o = New-Object System.Management.ManagementObject('root\wmi', 'MSI_ACPI.InstanceName="ACPI\PNP0C14\0_0"', $null)
$o.Get()
"BIND OK: " + $o.Path.Path

(The doubled backslashes inside the quotes are required this time - please copy-paste as is.)

What each outcome means:

• BIND OK: ... printed → hypothesis confirmed. I build a test version of GhostDeck that falls back to exactly this binding whenever the normal listing fails, and ask you to try it - good chance your Delta 15 starts working.
• The same "not supported" error again → hypothesis refuted; then the next suspect is that MSI's newer SDK reaches the EC through one of the other classes on your machine (MSI_AP, MSI_Device, ...), and I will prepare a different set of probes.

[SavAlexander]

The query returned an error, so I made a few adjustments with Claude's help. Hopefully this will be useful.

3_response.txt

[wygodad]

Thanks. This output confirms the class schema and qualifiers, but two things in it cannot serve as a verdict:

• $o.PSBase.Path.Path only prints the path stored in the local object - it does not prove WMI fetched a real instance behind that path (only .Get() or a method call does that).
• $Error[0] cannot identify which earlier operation failed, because the command that populated it is not in the paste.

So the direct-bind question is still open. The leading firmware-side hypothesis - unverified - is an inconsistency between the healthy BMOF class definition and the runtime ACPI-WMI registration for this GUID (for example wrong _WDG flags, object id or instance metadata, or a duplicate registration). Verifying it needs ACPI tables, but first the two tests below, because they decide whether this exact-path MSI_ACPI fallback is feasible.

To avoid the paste problems from last time, please run it as a file this time:

1. Copy the whole script below into Notepad.
2. In Notepad's Save As window set Save as type: All files (.), then save the file in your Downloads folder as ghostdeck-diag.ps1. (With the default "Text Documents" type Windows would silently create ghostdeck-diag.ps1.txt.)
3. Open PowerShell as Administrator and run:

powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "$env:USERPROFILE\Downloads\ghostdeck-diag.ps1" *> "$env:USERPROFILE\Downloads\ghostdeck-diag-output.txt"

4. The command intentionally writes its output to the file rather than the console - so the console showing nothing is expected. When the prompt returns, attach ghostdeck-diag-output.txt here.

The script (read-only, prints an explicit PASS/FAIL for each of the two operations we need to tell apart):

$Error.Clear()

function Show-WmiError {
    param([System.Exception]$Exception)

    $e = $Exception
    $wmiException = $null

    while ($null -ne $e) {
        if ($null -eq $wmiException -and
            $e -is [System.Management.ManagementException]) {
            $wmiException = $e
        }
        if ($null -eq $e.InnerException) { break }
        $e = $e.InnerException
    }

    "Exception type: $($e.GetType().FullName)"
    "Message:        $($e.Message)"
    "HRESULT:        0x{0:X8}" -f $e.HResult

    if ($null -ne $wmiException) {
        "WMI status:     $($wmiException.ErrorCode)"
    }
}

$namespace  = 'root\wmi'
$objectPath = 'MSI_ACPI.InstanceName="ACPI\PNP0C14\0_0"'

Write-Host "`n=== TEST A: fetch the instance directly by path ==="
$o = $null
try {
    $o = [System.Management.ManagementObject]::new($namespace, $objectPath, $null)
    $o.Get()
    "TEST A GETOBJECT: PASS"
    "Resolved path: $($o.Path.Path)"
    "InstanceName:  $($o['InstanceName'])"
    "Active:        $($o['Active'])"
}
catch {
    "TEST A GETOBJECT: FAIL"
    Show-WmiError $_.Exception
}
finally {
    if ($null -ne $o) { $o.Dispose() }
}

Write-Host "`n=== TEST B: invoke Get_EC directly without Get() ==="
$o = $null
$result = $null
try {
    $o = [System.Management.ManagementObject]::new($namespace, $objectPath, $null)
    $result = $o.InvokeMethod('Get_EC',
        [System.Management.ManagementBaseObject]$null,
        [System.Management.InvokeMethodOptions]$null)

    $data = [System.Management.ManagementBaseObject]$result['Data']
    [byte[]]$bytes = $data['Bytes']
    if ($null -eq $bytes) {
        throw [InvalidOperationException]::new('Get_EC returned no Data.Bytes buffer.')
    }

    "TEST B GET_EC: PASS"
    "Hex: " + (($bytes | ForEach-Object { $_.ToString('X2') }) -join ' ')

    $text = [System.Text.StringBuilder]::new()
    for ($i = 2; $i -lt $bytes.Length -and $bytes[$i] -ne 0; $i++) {
        if ($bytes[$i] -ge 32 -and $bytes[$i] -lt 127) {
            [void]$text.Append([char]$bytes[$i])
        }
    }
    "ASCII: $($text.ToString())"
}
catch {
    "TEST B GET_EC: FAIL"
    Show-WmiError $_.Exception
}
finally {
    if ($null -ne $result) { $result.Dispose() }
    if ($null -ne $o) { $o.Dispose() }
}

What each outcome means:

• TEST B passes: direct method invocation through the exact instance path works for Get_EC. This makes a GhostDeck fallback plausible and worth testing, but the test build must still verify Get_Data before we can say that EC access itself works. The ASCII line should contain your EC firmware version (expected: 15CKEMS1.108). I will then build a read-only test version that uses the exact path and verifies Get_Data.
• TEST A fails but TEST B passes: same conclusion - GhostDeck may be able to call the methods directly without enumerating or fetching the object first; that is exactly why the test is split in two.
• TEST A passes but TEST B fails: the instance can be fetched, but the EC method route is still unusable - a fetch alone is not enough for GhostDeck.
• Both fail with NotSupported: this exact-path route through MSI_ACPI is not usable. That does not exhaust the software options yet - the next high-value step would be inspecting the firmware's ACPI _WDG mapping for this GUID and comparing it with a working MSI laptop; I will prepare exact instructions if we get there.

Both tests are read-only.