Hi folks! I know that you mostly know me from my consulting days, or my blog posts about PowerShell and making tools or building services. But I also am a gamer, and more recently, a modder, and I wanted to share about my Balatro Mod, Fickle Fox, here!

Fickle Fox

An animal themed, vanilla friendly, configurable Balatro mod!

Download the mod here! FickleFox

Report issues or suggest ideas in the Discord! Or file an issue on the repo!

What’s the purpose of this mod

The themes and goals here are cute art and fun new options for all phases of the game, especially late game / naninf.

I felt that it would be fun if there were more long term options available for late / end-game, and especially if these new jokers were fun or changed the way you play the game!

What’s in this mod

This mod contains a lot of fun stuff, including 40+ fun and original Joker ideas, all of which have lovingly handcrafted art and deep interactions with each other as well as the full set of original Jokers from the base game!

40+ new jokers!

5+ new boosters

New Editions, Vouchers, Decks and more!

Just a sampling of the Joker’s you will discover!

To do

Changelog

Special Thanks

• Thanks to OhPahn for some programming tips especially around custom sounds, and for contributing an adorable doggo joker! You can learn more about him here, be sure to check out his music and also his own Balatro mod OhPahndora’s Box, with plenty of original tunes!

• Special thanks to MarioFan597 for his very helpful artistic advice and guidance, and deep knowledge of the Balatro art style and for contributing two jokers and offering advice on countless others. You can read more from them here, and be sure to check out their very cool Cryptid Friendly mod: MarioFan’s Ascensio Mod - Github

• Special thanks to my real life best friend Akravator for contributing one of the Secret Jokers in this mod!

Extra Special Thanks

And my deepest thanks to my wife, Linzra for brainstorming and creating 95% of all of the art in this mod!!! You can read more about her here

Installation Instructions for Windows

Setup Lovely and Steammodded following this guide on Steam

Download the newest release from

Navigate to this path (using the Run Command box or paste into explorer)

• %AppData%/Balatro
• If you’re not familiar with app variables you can also navigate here
• • C:\Users<YourUserName>AppData\Roaming\Balatro

Create a new folder at this path if it does not exist yet: Mods

Unzip the release, it should look like this when done

Installation Instructions for Steamdeck

The steps are surprisingly similar to the Windows release, thanks to the way the Steamdeck’s Proton layer enapsulates a Windows like folder and file structure.

You can follow this guide to get started, How to mod Balatro on Steam Deck

• tested on Steammodded Version 1.0.0-beta-0509c

Recently, this issue popped up :

How do I make sure people change their content…in the right way

Post Outline

I’m working on a project now in which UX is created on the fly directly from some JSON content that partner teams provide to us. It’s very cool and fun work.

However…after some time has gone by I began to realize somethings…

1. We create UX on the fly from partner inputs
2. It requires a PR to update this content
3. I am not the only one allowed to approve PRs

What then would happen if someone alters a json content file after its been in use in testing for months and the new file breaks things? I’ll tell you what doesn’t happen, people don’t go to the author of the file and ask them why they made a change, no, they instead line up to ask me questions. Me, the bozo who developed this platform and didn’t think to check for things like that!

The problem

It’s very simple to run a test against all of the code in a repo at check in. We do this in the Azure world by creating a new pipeline that runs on a hosted pool and we set the input source to be the repo in question with the trigger type being pr, then at the end of the day, run a PowerShell script to perform your tests (I prefer to do this in Pester).

But I don’t need to just test their current version of the file. I need instead to compare the file to its previous state in master, otherwise I won’t be aware of just how much its changed.

I mean, I could know if I looked at the PR, but there are times when it’s not possible to review every PR.

The Setup

We want to:

• Get a list of potential files to check ($allJsonFiles)
• Retrieve a list of files changed in this PR ($allChangedFiles)
• See if any of $allJsonFiles are in $allChangedFiles, and if so capture them as $myChangedJsonFiles
• Handle either 0 changed files or many files
• Do some quality checks
• Handling when I need a human set of eyes
• Call it a day and go get lunch.

It was very easy to get the list of files I cared about, the interesting thing was seeing what changed in this PR:

 $changedFiles = git diff --name-only master    

This will give you a list, in linux file format, of all files that changed in your commits/pr versus master.

This actually failed aggresively, as it turns out that ADO pipelines will by default only include the dev branch and won’t mirror master as well. I added this to fix that particular issue.

 git fetch origin master
$changedFiles = git diff --name-only master    

From here, it was simple enough to compare $allJsonFiles against the list back from $allChangedFiles and filter things down. I then ended the BeforeDiscovery block of my test by publishing $myChangedJsonFiles.

Next up, it’s very easy to hand a list of resources off to a Describe block and iterate over them, using this syntax:

Describe "Catalog JSON File - <_.FullName>" -ForEach $jsonFiles {
    BeforeAll {
      #load the json file, convert from json, etc

How to get a human to pay attention

I decided that certain values in a partner file need to be immutable after their first check in. We could handle changes to them on a case by case basis, but enshrining this with checks would keep everyone safe.

I found that if I skip a test in ADO, this triggers a warning exit status, which helps to draw human eyes to reviewing the problem. Here’s how I did it.

    if ($difference -ge 1) 
            {
                Write-Warning "WARNING - Detected $difference in status between this file and master.  Does this make sense?"
                Set-ItResult -Skipped -Because "Human Review Required - Significant change in 'ShouldNeverBeChanged' settings detected, with a count of $difference."
                return
            }

It was that easy!

Time for lunch.

Ever wish you could see your test results in the same clean, organized view you get when running tests in an Azure DevOps pipeline?

If you’re like me, you’ve probably opened those XML files in a text editor more times than you’d care to admit, scrolling through endless <test-case> elements, trying to make sense of the results. There has to be a better way 🎃!

Well, now there is.

👻 Introducing: nUnit Test Results Viewer 👻

This single-page application takes your nUnit XML test results and renders them in a beautiful, pipeline-style view that makes it easy to understand your test outcomes at a glance.

No more squinting at raw XML trying to count passed vs failed tests, or hunting through massive files to find that one test that’s been causing issues.

Think of it as “Azure DevOps Test Results tab,” except it works with any nUnit XML file and runs entirely in your browser.

Features

• Pipeline-style test visualization - See your test results organized just like in Azure DevOps
• Test summary dashboard - Get an instant overview of passed, failed, and skipped tests
• Expandable test details - Click into individual tests to see failure messages and stack traces
• Search and filter - Quickly find specific tests or filter by status
• Runs entirely in your browser - No installs, no servers, no hassle
• Complete privacy - Your test results never leave your browser
• Janky CSS - Look, you get what you pay for.

How to Use It

Simply upload your nUnit XML results file or paste the XML content directly into the viewer. The app will parse your test results and display them in an organized, easy-to-read format that mimics the test results view you’re familiar with from Azure DevOps pipelines.

It’s Completely Private!

There’s no telemetry, monitoring, or data collection of any kind. Your test results stay completely within your browser tab - nothing is ever sent to a server or stored anywhere. Don’t believe me? GOOD!

I mean if you don’t believe me, just check your network traces tab in devtools.

If you’ve ever spent way too long trying to parse XML test results by hand, this tool will save your sanity (and probably some time too).

Give it a try here: nUnit Test Results Viewer
And if you find any bugs, well… at least now you’ll have a nice way to view the test results when you fix them! 😉

It’s been seven years since I last attended Ignite, and I couldn’t be more excited to finally be heading back! I miss the energy, the pizza, the inevitable colds you get from conferences. I especially miss the subzero artic air conditioning which is always on at conventions!

This year, I’ll be helping run the Configuring a Modern Workplace lab and spending time at the Microsoft Booth in the Azure / Configuration areas. If you’re walking the floor and want to chat about Policy, Configuration, or distributed systems, swing by—I’d love to connect.

Why this year matters

Ignite has always been about the crowd, the connections, and the energy. After so long away, I can’t wait to see the community again, share stories, and hear how everyone is using these tools in the field.

I’ll also be dropping into the PowerShell meetups during the week. PowerShell is still one of my favorite ways to build, automate, and experiment—and I know that crew always brings the best energy.

Where to find me

• Configuring a Modern Workplace Lab – I’ll be co-hosting and helping folks get hands-on.
• Microsoft Booth (Azure / Configuration) – Stop by, say hi, and let’s talk shop.
• PowerShell Community Meetups – You know where the cool kids hang out.

If you’ve ever read one of my blog posts and thought “hey, I should say hi if I ever see him at an event”—this is the time!
I’m looking forward to seeing old friends, meeting new ones, and getting back into the Ignite groove.

See you in San Francisco! ✨

Ever cracked open an Azure Policy JSON file and felt like you needed a PhD in indentation archaeology just to figure out what OSes are allowed?
Ever find yourself squinting at a sea of anyOf and allOf blocks like they’re some arcane magical incantation?
Ever thought: “surely there must be a better way than ctrl+F’ing for Ubuntu for the fifteenth time”?

Yeah, me too. So I built something.

Introducing: Azure Policy OS Allowlist Viewer 🎉

This little single-page app lets you paste in a Policy JSON blob and instantly see:

• A Publisher Allowlist: the raw, explicit imagePublisher values your policy permits
• An OS Version Summary: a concise cheat sheet of “Versions like 8* / 9” or “Versions NOT like 6 / 7*”

Think of it as “Clippy for Azure Policy,” except instead of asking if you’re writing a letter, it tells you if you’re about to allow RHEL 6 (spoiler: you’re not).

Features

• Expand and collapse nested policy clauses like a file tree
• Auto-builds a human-readable summary table for quick reference
• Zero dependencies: runs entirely in your browser
• Total privacy: nothing leaves your tab

It’s private!

No telemetry, no API calls, no uploads. Everything happens in-memory.
Paste your JSON, hit Parse, and get instant clarity. When you close the tab, it’s gone.

If you’ve ever tried explaining to your boss which OSes your policy actually allows and felt like you were doing improv stand-up with JSON, this will save you.

Check it out here: https://www.foxdeploy.com/PolicyOSView/
And if your summary table shows “Versions NOT like 6* / 7*,” just tell your auditors you know what you don’t like!

Do you kind of just want to go back to using Orchestrator again, or hell, just go back to 2007 again? Maybe get back out your old emo clothes? Do you miss $2 Pabst Blue Ribbons at dive bars, fighting games and Halo and chatting with your friends till 2 AM a few nights a week? Staying up, just to watch the sunrise?

Yeah… me too. Anyway now I am despressed so I guess I will have to build something new!

Well that was depressing, let’s pivot

Introducing: Azure DevOps Pipeline Viewer / Editor 🎉

This little web app lets you open, browse, and edit your ADO pipeline JSON files in a clean, easy to read view.

No more having to check your pipeline in or put up with pesky peer reviews, just to see if you got your stages in the right order.

Think of it as “Windows Explorer for your pipeline,” except it won’t randomly decide to apply dark mode at 2 AM.

Features

• Expand and collapse pipeline sections like a file tree
• Inline JSON editing without losing your place
• Quick search to jump to the setting you need
• Runs entirely in your browser — no installs required
• Total privacy

It’s private!

There’s no telemetry, monitoring, exporting, downloading or anything else. So long as you upload or paste in your pipeline, it will all stay 100% within your browser tab.

If you’ve ever spent ten minutes scrolling to find that one step buried in a nested job definition, this will save your sanity (or at least reduce your coffee bill).

Give it a try here: https://www.foxdeploy.com/AdoPipelineView/
And if you break your pipeline JSON, don’t worry — that’s called job security. 😉

This is the story of how an innocent ZIP file became haunted, how PowerShell 5 doomed a build, and how I barely escaped with my sanity (and deployment pipeline) intact.

Observed behavior: things looked… fine?

We use YAML Pipelines in ADO which not surprisingly I find that I really enjoy. This is like the evolution of using System Center (or Opalis) Orchestrator to achieve complex automation.

And if you are surprised that I enjoy this, then you must be new here!

Well, Recently I needed to add a new folder into a zip we produce in our build process. I told management that this would be trivially easy, barely an inconvenience, only three days at max.

Previous to this point, all of our artifacts in our build would be single binary files, like .exe and .dll files and things. We’d take all the built bits, put them into our OUT dir and make a zip file out of the whole mess. Then our Release would grab the output and push it out to our regions and bam, it all just worked.

But we never added a folder to our build before.

How hard could it be?

Step 1: This should be easy, barely an inconvenience

I added a simple step to my PowerShell@2 task, copying recursively an entire directory and preserving its output structure

Then I ran my release script, which was super simple, just launching a task on one of my Linux agents to run the task of grabbing my content and pushing it out to the expected location on this storage account.

So I ran my release process and saw that it looks like we see the files, but uploading them to a storage account failed with Cannot find the specified file

What do you mean you can’t find the files? But it’s right there!!

I made sure that my output appeared under ‘Artifacts\Published’.

Ok, let me open the zip file too just to be safe.

Step 2: Add logs like a panicked developer

I cracked open the logs and saw the files were definitely there. PowerShell said so!
And yet… Set-AzStorage would just give me a shrug emoji and die.

At this point I began adding all sorts of logging, Get-ChildItem, ls, dir and even [System.IO.FileSearcher] dumps, even ASCII art.

The files seemed to be visible, but any operation trying to touch them would explode:

• Get-Item? Nope.
• Upload-Item? Also broken.
• Even using -Include or -Filter? Instant failure.

Check this out for proof! Even a Get-ChildItem, the holiest and most chosen of cmdlets would explode.

Look at this, I cannot even GCI in here

Have you ever seen that? Get-ChildItem throwing!?

Step 3: this has got to be related to the host environment

At this point I began questioning a lot of things. My Career choices, political affiliation, even my preference for coffee over tea and bourbon over tequila.

What could this possibly be?

I decided to remote out to one of our Release env boxes, which is in ADO so its really just a container running some remote os to run a PowerShell script and do stuff.

I noticed these are Linux containers…so I used SSH. I found here that doing directory commands on the new files were really odd… like I couldn’t CD into the myNewFolder folder at all.

But I could cat or grep on them using bash commands. However using PowerShell commands would fail. Now why would that be?

Fine, I guess I will try reading

>ls

Wait a minute…

The Slashes Were Wrong

The paths weren’t just inconsistent. They were… interleaved.

How the hell do you even end up with Slashes in this direction on a Linux machine?!

At this point I was just impressed with the degree of my mess up. I deleted the directory, pushed the zip file back over again and opened it in front of my own eyes.

zip appears to use backslashes as path separators

How did I manage to get a Zip file wrong?

Honestly I was kind of proud of myself. This was a whole new genre of spectacular disaster. I was charting new territory here.

I had succeeded in making files exist on a linux box was the full Amuse-bouche of possible characters in their names:

• some with backslashes
• some with forward slashes.
• some with both.

I wouldn’t have been surprised to find that some had a cream filling!

Here’s the crux of the issue then, for some files, the slash wasn’t a path separator - it was part of the literal file name.

In Linux, a slash facing the wrong way doesn’t mean that the file is safely nestled in a folder like that guy inside of the Bantha in Star Wars, it means a file named "Controllers\HomeController.cs".

Like, no folder at all. Just one cursed file.

Root cause: PowerShell v5 Zips Wrong™

The ZIP file had been created using PowerShell 5 in a Windows container. And here’s where the real goblin comes in:

PowerShell v5’s Compress-Archive writes entries with Windows-style backslashes.
Not as path separators. As actual filename characters.

When you unzip that on Linux? Congratulations, you’ve just summoned a cursed archive where:

• Controllers\HomeController.cs is a file, not a folder + file
• Nothing works because no tools expect this
• PowerShell is confused, .NET is confused, I’m confused

Yes, this has been a known bug for years.

But PowerShell v5 is built into Windows and I do not think this particular thing is getting fixed because you never know, some company out there making critical life saving widgets might have built their entire production line workflow depending on this behavior of zip files.

I don’t know, not my department.

Wrapping it all up

• Get-ChildItem could see the file just fine, since PowerShell is slash agnostic
• But $_ .FullName or .ToString() rewrote the slashes to forward ones
• So Upload failed because it passed the wrong path
• -Include and -Filter (which hit the provider layer) failed completely due to the implicit conversion of slash direction
• Meanwhile piping into Where-Object worked, because it stayed object-based and so PowerShell could navigate around that

This led to the haunting bug where I could see a file, but not act on it.
Even Copy-Item and Test-Path failed.

And yes you are right, I could have fixed this by using -LiteralPath but I really wanted to fix the underlying issue. You deserve a cookie for thinking about this as a fix, treat yo’ self.

The Fix: PowerShell Core (v7+) to the Rescue

Once I figured this out (after many wasted hours and caffeine), the fix was simple:

Run the ZIP creation step in PowerShell Core.

PowerShell 7 uses System.IO.Compression.ZipArchive in a way that correctly encodes folders using forward slashes as expected. And not as part of the file name. Wild, right?

Suddenly:

• Files extracted into real folders
• Uploads worked
• Slashes stayed in their lane
• I slept better

It was literally as simple as adding pwsh: true to my YAML pipeline file.

Why the eff is this even a difference in Windows and Linux?

This is really interesting. I’d heard a lawsuit was involved in some distant point in the path but maybe not, maybe it was all just as simple as ‘This is how IBM did it’. In any case, you can read for yourself here

Final Thoughts: Don’t Let This Happen to You

This was a perfect example of a cross-platform edge case that seemed fine—until it hit a different environment. PowerShell did what it was told… it just told no one what it actually did.

If you’re:

• Using Windows-based build agents
• Creating ZIPs in PowerShell v5
• Deploying those ZIPs on Linux containers

Switch to PowerShell Core now. Save yourself. Save your pipeline. Save your sanity.

This bug was never fixed in Windows PowerShell.
The fix is easy—just use the modern shell.

But if you’re like me, you can still use PowerShell ISE just to annoy your coworkers.

So, the process I took here was to first build a new Function App of type Queue Trigger, and configure it to use a Connection String to connect.

Once I had my Queue Trigger created, I looked at the docs for Azure Functions to see the requirements for using Managed Identities.

Docs Link

According to these docs, I need to update to Azure Queues Extension version 5.0.0 or later, so I did that first.

Next, the docs say that to configure Azure Functions to use an MSI instead of an environmental variable for connectionString, we simply add a new variable to our local.settings.json file.

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "AzureWebJobsStorage__queueServiceUri": "https://testorageaccount22.queue.core.windows.net/testiam"
  }
}

I added the AzureWebJobsStorage__queueServiceUri value, this is just set to the storage account I am using. According to the docs, when you’re using Azure Function Extensions v5 or higher, setting this config value instructs the Azure Function runtime to try and connect using a MSI.

To me, this is extremely non-intuitive and very confusing, but that’s how it’s done right now.

Next, I updated the signature of my function to be sure it is referencing the value from my settings file.

//from 
//public void Run([QueueTrigger("testiam2", Connection = "connectionString")] QueueMessage message)

//to
public async Task MsiQueueAccess([QueueTrigger("testiam", Connection = "AzureWebJobsStorage")] QueueMessage message)

Note how the Connection contains ‘AzureWebJobsStorage’, while the same settings prefix is found in the json file as well. That specific value is what triggers the new MSI features.

So let’s see what happens when I fire it up!

Host lock lease acquired by instance ID '000000000000000000000000527A19E4'.
[2025-01-22T16:48:16.609Z] An unhandled exception has occurred. Host is shutting down.
[2025-01-22T16:48:16.612Z] Azure.Identity: ManagedIdentityCredential authentication failed: Service request failed.
[2025-01-22T16:48:16.614Z] Status: 503 (Service Unavailable)
[2025-01-22T16:48:16.615Z]
[2025-01-22T16:48:16.616Z] Content:
[2025-01-22T16:48:16.616Z] {"error":"service_unavailable","error_description":"Service not available, possibly because the machine is not connected to Azure or the config file is missing. Error: missing required agent config properties. Current agent config: {Subscriptionid: Resourcegroup: Resourcename: Tenantid: Location: VMID: VMUUID: CertificateThumbprint: Clientid: Cloud: PrivateLinkScope: Namespace: CorrelationID: ArmEndpoint: AtsResourceId: AuthenticationEndpoint:} (config file location: C:\\ProgramData\\AzureConnectedMachineAgent\\Config\\agentconfig.json). Connection status: Disconnected. Check Agent log for more details.","error_codes":[503],"timestamp":"2025-01-22 11:48:16.5491276 -0500 EST m=+544299.660283901","trace_id":"","correlation_id":"97f841ea-68cd-4521-8278-3e8537341acf"}

Do I even have a Managed Identity Yet?

Hmm, that does not look like success. I noticed that the Subscription, Rg and all of those fields are all empty, likely because my dev laptop does not have an MSI on it. I was assuming this would be smart enough to try and use the same flow as DefaultAzureCredential, but I guess not.

So let’s instead enroll my machine in ARC to see what happens when there is an MSI associated…

With that done I can now view the resource in Azure and see the Managed Identity which was created for me.

You can view the MSI created for an Arc device by looking at the ‘Resource JSON view’, and see it’s GUID.

Now, to go to my storage account and give this identity (which Helpfully I can assign just by the name of the machine, not the guid displayed) some permissions to interact with the storage account.

I assigned it ‘Storage Blob Data Owner’ perms and then restarted the app.

Now I have a different problem, instead of an error saying that I don’t have an Managed Identity, I get this error that I can’t access the Tokens directory.

To fix this, I navigated to the directory and gave myself owner rights (suitable for debugging, and not needed in prod when this is deployed to a real worker with a real MSI).

And now a different error. The storage account does not exist?

OH I had the format of the URL incorrect, it should not include the name of the queue as I had done.

Before
    "AzureWebJobsStorage__queueServiceUri": "https://testorageaccount22.queue.core.windows.net/testiam"

After
    "AzureWebJobsStorage__queueServiceUri": "https://testorageaccount22.queue.core.windows.net/"

And now to restart once more…and now a new error!

I thought about it and realized I granted Azure Blob Storage Data owner perms but don’t recall doing anything related to queues, so lets try adding that too. I specifically added the Azure Queue Storage Contributor role this time and when I fire it up….

Success!

Quick Takeaways

The big takeaways here are:

• It IS possible to test Managed Identities on a normal dev machine or laptop, you’ll just need to enroll the machine in Arc to assign a managed identity
• You can use the automatic System Assigned MSI for your machine or any user created MSI
• You will need to assign these permissions to the Managed Identity
• • Subscription Reader for the sub holding the Storage Account
• • Storage Data Owner permission for the Storage Account
• • Storage Queue / Table / Blob Contributor for the Storage Account
• When assigning to Prod, instead use User Assigned Managed Identities so one MSI can be shared on your prod devices within a region, for ease of management

Some other weird takeaways is that all of this is configured using appSettings.json files, and namely some properties with very unintuitive names, like AzureWebJobsStorage_StorageAccountUri. To me, this feels like something that will likely change in a future release, so I would keep my eyes on this area.

TLDR

The three most important things are:

• be sure you upgrade to Extensions version 5 or higher
• change your Queue Triggers Connection parameter to match the prefix of the setting in your json file (see example image below)
• go to your local.setttings.json file and add a setting of prefix___queueServiceUri for queues, or the other values for other types of Azure Storage based triggers

Wait, prefix what?

I know, I know, this stuff was rather hard for me to understand too and took a half a day to figure it out.

Many of these offer a dayofweek function, but in many cases, these will give you a timespan interval since the previous Sunday. I don’t know about you, but for me, it’s very hard to just look at 1.00:00:00 and think “Oh yeah thats a Monday!

The query

Here is, short and sweet.

let weekday = (day:int) {        
        case(
        day == time(1.00:00:00), "Mon",
        day == time(2.00:00:00), "Tue",
        day == time(3.00:00:00), "Wed",
        day == time(4.00:00:00), "Thu",
        day == time(5.00:00:00), "Fri",
        day == time(6.00:00:00), "Sat",
        "Sun")
    };
    print weekday(1d);   

Result:

Mon

And a full working example

let weekday = (day:int) {        
        case(
        day == time(1.00:00:00), "Mon",
        day == time(2.00:00:00), "Tue",
        day == time(3.00:00:00), "Wed",
        day == time(4.00:00:00), "Thu",
        day == time(5.00:00:00), "Fri",
        day == time(6.00:00:00), "Sat",
        "Sun")
    };    
   range input from 0d to -6d step -1d
   | extend AsDate = ago(input)
   | extend AsWeekDayInt = dayofweek(AsDate)
   | extend AsDayOfWeek = weekday(AsWeekDayInt)

Result:

But first, a rant

LG, Do better.

It’s not enough that the hardware is all controlled by an extremely lagging always running control center app, but troubleshooting it becomes a nightmare, as LG does not bother to write any TSGs or per device guidance.

LG does not publish drivers either, so if you’re looking to deploy en masse, you’ll have to do the nasty of capturing reference drivers from a machine, so expect very tedious imaging as you build the needed drivers.

You also do need to include the control center software too, or risk users ending up in this scenario I encountered.

The user plugged their LG Gram into their husband’s docking station with external monitors on a thunderbolt dock.

When an external mouse is connected in such a manner, the touchpad is disabled for unknown reasons.

The laptop went to sleep and was disconnected from the dock. This left the user with no way to re-enable their touchpad, although at least the touchscreen still functioned.

The fix

To fix this, look at Device Manager, in this scenario there was no HID Driver Compliant Touchpad Driver present on the device.

There was however a Device which failed to start, called ‘I2C HID Device’ or something like that. In our scenario, we uninstalled this device and then restarted the laptop.

On reboot, the device worked again.