#Debugging script after integrating it into tweaks.json

1 messages · Page 1 of 1 (latest)

bright jolt
#

I wrote a script for disabling/enabling the new 25H2 Start Menu layout. I've verified that the standalone script (as in, the .ps1 file) works correctly when ran from an elevated powershell.
I then proceeded to integrate it into tweaks.json. Running Compile.ps1 -run works as expected, without raising any errors. However, when attempting to run the script from within WinUtil, the following cryptic exception is thrown:

WARNING: A runtime exception occurred.
WARNING: The argument is null. Provide a valid value for the argument, and then try running the command again.

I pinpointed the warning being printed by Invoke-WinUtilScript.ps1 in line 31 by the following code:

} catch [System.Management.Automation.RuntimeException] {
        Write-Warning "A runtime exception occurred."
        Write-Warning $PSItem.Exception.message
} # ...

so I attempted to print a stack trace in the same catch block in a few different ways as to get some idea how it fails like so:

$_.Exception.Message
$_.Exception.StackTrace
$_.ErrorDetails
$_.ScriptStackTrace
$PSItem.Exception.StackTrace

but I got nothing.

The only thing I can suspect is that, because I am using some C# code via Add-Type, Invoke-Command might be freaking out about the @ characters? I genuinely got no clue about how to tackle this. Any pointers would be very helpful!

peak lynx
bright jolt
bright jolt
peak lynx
#

you could probaly make the code less complicated, also i would debug this by removing part of the code until it works and seeing which exact part is wrong also update your brance

bright jolt
peak lynx
#

which premsion do you need to modify the registery?

#

also dont use | Out-Null we can't see it

#

and your using alot of c# code (not talking about the defeintions)

#

you shouldn't accses the registery with c# code

bright jolt
# peak lynx which premsion do you need to modify the registery?

Well I need to set the EnabledState key value. So I need write permissions HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\0\3036241548. I checked the default key permissions on a fresh windows install and indeed, the Administrators have only read access

bright jolt
bright jolt
# peak lynx you shouldn't accses the registery with c# code

I disliked that approach myself, but it was genuinely the only one that worked, I tried setting ACL and what not with "pure" powershell for hours but it just wouldn't work. I didn't think of running as Trusted Installer though, or at least, I thought it would be improper to do so for a winutil script. Thanks a lot for suggesting that, I will try it

#

codeblock it

peak lynx
#

you can make a script to download vivetool to temp and run it

bright jolt
peak lynx
bright jolt
#

Ok, I will most likely do that then. I wanna try trusted installer first though just in case it works without all the C# crap and it massively simplifies the script

#

Thank you so much for your help

peak lynx
bright jolt
#

Do tell?

peak lynx
#

i well need to make it first it well take like 2 minutes

bright jolt
#

Gotcha, anything is appreciated, I will try to read up on it myself

peak lynx
# 
Register-ScheduledTask -TaskName "ti" -Action (New-ScheduledTaskAction -Execute "powershell" -Argument "Set-ItemProperty -whatever") -User 'NT SERVICE\TrustedInstaller'
peak lynx
bright jolt
#

Ok, I will try it out right now

peak lynx
bright jolt
peak lynx
bright jolt
#

It's the vive library + the tool that consumes it

peak lynx
bright jolt
#

Ahh, well I pieced it up together from a couple of different places.
I knew that running vivetool.exe /enable /id:47205210 (and /disable respectively) did what I wanted.
So I started from ViVe/ViVeTool/Procram.cs and from the /enable case. I ended up using the following as my reference:

  • The RTL_FEATURE_ENABLED_STATE that is being used in Program.cs to get the key values I'd need
  • I found the feature override path in ViVe/ViVeTool/FeatureManager.cs in line 216. Initially I wasn't able to find the corresponding registry key in Registry Editor, but obviously it was being de-obfuscated so to get the actual ID I needed, I copied the obfuscator code from ViVe/ViVeTool/ObfuscationHelpers.cs, ported it to a quick C function, opened Compiler Explorer and passed the ID 47205210 to it to get 3036241548.
#include <stdint.h>
#include <stdio.h>

static uint32_t SwapBytes(uint32_t x)
{
    x = (x >> 16) | (x << 16);
    return ((x & 0xFF00FF00) >> 8) | ((x & 0x00FF00FF) << 8);
}

static uint32_t RotateRight32(uint32_t value, int shift)
{
    // Normalize shift to 0-31 range
    shift = shift & 31;
    return (value >> shift) | (value << (32 - shift));
}

uint32_t ObfuscateFeatureId(uint32_t featureId)
{
    return RotateRight32(SwapBytes(featureId ^ 0x74161A4E) ^ 0x8FB23D4F, -1) ^ 0x833EA8FF;
}

int main(void) {
    printf("ID: %u", ObfuscateFeatureId(47205210));
    return 0;
}
peak lynx
bright jolt
# peak lynx thanks

Also, if you're curious about the "number" (name) of the subkey in Overrides, this enum seems to explain it. It can vary from install to install, hence why I am looping through these

public enum RTL_FEATURE_CONFIGURATION_PRIORITY : uint
{
    ImageDefault = 0,
    EKB = 1,
    Safeguard = 2,
    ImageDefaultEditionOverride = 3,
    Service = 4,
    Dynamic = 6,
    User = 8,
    Security = 9,
    UserPolicy = 10,
    Test = 12,
    ImageOverride = 15
}
bright jolt
#

@peak lynx I got it working using TrustedInstller, thank you! Let's hope it works from within winutil too :P

bright jolt
#

Unfortunately, it's still problematic when run from within WinUtil :(
I pushed the updated script to the fork

bright jolt
#

I actually got it to work through WinUtil, the function I made to set the key value as trusted installer works, it fucks up somewhere down the toggle logic. Honestly, I will just make the invoke set it to disabled and the undo set it to enable, that way it's also gonna be simpler

bright jolt
#

For anyone who might stumble upon this:
It is a JSON formatting problem, I can't say what exactly I did wrong, but rewriting it worked. Something tripped up Invoke-Command (most likely in the escaping or how nested quoting was done).