svnscha - automation

AI Meets WinDBG: A Different Way to Analyze Crashes

2025-05-04T00:00:00+00:00

Old Meets New: Bringing Crash Analysis into 2025

Let's face it - while the rest of software development has evolved at warp speed, crash dump analysis feels like it's been preserved in digital amber for decades. We've got self-driving cars and pocket-sized supercomputers, yet here we are, still pecking away at command prompts like it's the dawn of the internet. Why is debugging the only area where we cling to tools that look like they belong in a computer history museum?

Picture this: You, a professional software engineer in 2025, hunched over a terminal, manually typing arcane commands like !analyze -v and .ecxr, squinting at hexadecimal memory addresses, and mentally translating stack traces. All while your friends in other industries are delegating their work to AI assistants that can write entire documents, create art, or automate complex workflows.

Something's wrong with this picture, right?

I wanted a simpler workflow: ask questions in plain language and let an AI assistant run the relevant debugger commands. This is more than a new interface for WinDBG; it changes how you interact with the debugger.

When Inspiration Strikes

During a debugging session at work, I had one of those lightning bolt moments. What if - and stick with me here - we could apply the same AI-assisted "vibe coding" approach to crash dump analysis?

Picture this: instead of manually slogging through memory dumps and command outputs, you simply ask, "Hey, why did this application crash?" and get an intelligent, contextual answer that actually helps you solve the problem.

The idea was too compelling not to pursue. So I built it.

See It In Action: AI-Powered Crash Analysis

Before diving into the technical details, let me show you what this looks like in practice. I have prepared a demo application to showcase two different use cases:

Video 1: Crash Analysis and Automated Bugfix

In this video, I show how Copilot can analyze a crash dump, identify the bug and auto-fix the issue.

Your browser does not support the video tag.

As you can see in the video, instead of manually running WinDBG commands and interpreting the cryptic output, I'm having a natural conversation with GitHub Copilot. The AI quickly identifies that the application crashed, explains which specific conditions led to the crash, and suggests a fix.

Video 2: Automated Crash Dump Analysis of multiple crash dump files

This video demonstrates a different capability: analyzing multiple crash dump files at once. It shows how the tool can quickly identify which dumps belong to your application and which don't.

Your browser does not support the video tag.

Worth noting, it takes just a few seconds until you get your first useful answer. I've played around with this for many hours and let me tell you one thing: You can really go deep. If you ask the right questions, the AI runs WinDBG/CDB commands that I haven't seen in all these years of debugging, and that is simply amazing.

How can this help the industry?

I believe this is one of the really good examples of how AI can boost productivity. Analyzing crash dumps is a very tedious task. It begins with quickly checking and identifying whether crashes are the same or different, and often requires very advanced knowledge when a crash is challenging - really challenging.

Copilot can help here tremendously; it knows how to:

Interpret assembly code (without you having to remember what EAX stands for)
Check memory contents (so you don't have to count hex bytes on your fingers)
Traverse structures with symbols (goodbye to manual pointer arithmetic!)
And so much more

This can help engineers, support teams, and QA staff work with crash dumps without memorizing every debugger command.

How did I build this?

If you've ever worked with WinDBG, you know the drill: cryptic commands, obscure syntax, and endless scrolling through memory addresses and stack traces that make your eyes glaze over. It's the kind of specialized knowledge that takes years to master and feels like speaking an alien language even when you do.

The trick here is connecting WinDBG with AI. To do that, you first need to programmatically control a debugging session, right? There are plenty of options on how to do this. I prefer to keep things simple, so I have chosen CDB, which is Microsoft's Console Debugger. It operates on standard input and output, and that's so much more fun to deal with than setting up COM APIs or similar approaches.

The second part is "connecting with AI." That's where Model Context Protocol Servers come into the game.

Understanding Model Context Protocol Servers

MCP is an open standard developed by Anthropic, released in November 2024. This protocol allows AI models to interact with external tools and data sources - think of it as giving AI assistants "hands" to work with other software. It defines a way for AI assistants to discover, access, and use tools through a consistent interface. In essence, it's what allows GitHub Copilot to "talk" to external programs like WinDBG.

An MCP server acts as the intermediary between the AI model and the tool. It:

Registers available tools with the client
Handles requests from AI models to use these tools
Executes the tool operations and returns results
Maintains context across interactions

Any tool can be made available to an AI model through an MCP server. I built one for WinDBG's CDB debugger.

Why MCP Instead of LanguageModelTool API?

The LanguageModelTool API might eventually be a better fit for this specific use-case. Creating a Visual Studio Extension that "just works" out of the box would potentially simplify the integration process significantly.

However, using MCP directly offers several notable advantages. It works with any AI model, not just limiting itself to Copilot. The server can be used outside VS Code, functioning with various other tools. New features can be easily added without necessitating changes to the core integration. Moreover, it remains platform-independent, avoiding lock-in to any single company's implementation.

The MCP-WinDBG Project

I've implemented a Model Context Protocol server that wraps WinDBG/CDB and exposes its capabilities to AI models within VS Code. Better yet, I've made it open source so everyone can experience this new workflow.

The project, mcp-windbg, connects VS Code and GitHub Copilot to WinDBG's analysis commands.

The actual "hard part" was implementing the CDB (Command-Line WinDBG) interaction layer. And by "hard", I mean vibe-coding with two coffees on a Saturday morning, where I spent more time being annoyed by pyTest failures than actual coding difficulties. The core implementation came together surprisingly quickly!

The rest is primarily wrapper code that implements the Model Context Protocol specifications. Now that I've established and defined the core WinDBG interaction logic, I'm considering refactoring the project to TypeScript. This would enable me to create both an MCP Server in TypeScript and a dedicated Visual Studio Extension, with both implementations leveraging the same underlying CDB interaction layer.

What Does This Mean In Practice?

Let me walk you through what this enables:

Natural language crash analysis: "Why is this application crashing with an access violation at this address?" (Instead of: "What the $%#@ is this heap corruption!?")
Contextual debugging: "Show me the stack trace for thread 5 and explain what each function is doing based on the symbols." (Instead of staring at call stacks like they're ancient hieroglyphics)
Root cause identification: "What's causing this null pointer dereference and where should I look in the code to fix it?" (Instead of playing detective with memory addresses)

Instead of typing obscure commands like !analyze -v followed by a series of manual investigations, you simply ask questions in plain language, and the AI interprets the crash data for you. It's like having a WinDBG expert whispering in your ear, except it doesn't get annoyed when you ask the same question five times.

How It Works

The MCP server connects GitHub Copilot to WinDBG:

It provides a set of tools that Copilot can use to interact with crash dumps
It translates natural language questions into appropriate WinDBG commands
It parses and interprets the often cryptic WinDBG output into more useful information
It maintains context throughout a debugging session, enabling follow-up questions to work naturally

The technical implementation uses Python to spawn and communicate with CDB (the command-line version of WinDBG), parses the output, and exposes the functionality through the Model Context Protocol to VS Code.

Getting Started With mcp-windbg

Ready to try it yourself? Here's how to get started:

First, make sure you have the Windows SDK installed with Debugging Tools for Windows
Clone the repository: git clone https://github.com/svnscha/mcp-windbg.git
Set up a Python virtual environment and install the package
Configure VS Code to use the MCP server

For complete details, check out the repository README.

Once configured, create a .vscode/mcp.json file in your project that points to the server:

{
    "servers": {
        "mcp_server_windbg": {
            "type": "stdio",
            "command": "python",
            "args": [
                "-m",
                "mcp_server_windbg"
            ],
            "env": {
                "_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
            }
        },
    }
}

You might need to update the command, depending on where and how you have installed the mcp_server_windbg to.

The Human Touch Still Matters

Just like with code refactoring, the AI assistance isn't perfect. The human element - your experience, intuition, and domain knowledge - remains crucial. Sometimes you'll need to guide the analysis, ask follow-up questions, or provide additional context.

The useful part is the combination: AI can process a large amount of debugger output quickly, while you provide the context needed to judge the result. It still needs supervision and can follow the wrong lead, so treat its findings as a starting point rather than a final answer.

Join The Experience

I'd love for you to try this out, contribute to the project, and share your experiences. If you're interested:

Star the GitHub repository
Try it on your own crash dumps
Report issues, suggest improvements, or contribute code
Share your success stories (or even failures - we learn from those too!)

The Magic Is In The Flow

Just like with my code refactoring experience, the real magic isn't about any single capability - it's about the flow. When debugging stops being a tedious chore and becomes a fluid conversation, something fundamentally changes in how you approach problem-solving.

Gone are the days of dreading crash analysis. Instead, each debugging session becomes an opportunity for collaboration with an AI partner that helps you understand what's happening at a deeper level.

Summary

Crash dump analysis has traditionally been one of the most technically demanding and least enjoyable parts of software development. It's like archaeology with a keyboard - painstakingly excavating through layers of memory and CPU state to unearth what went wrong. With AI assistance through tools like mcp-windbg, it becomes another area where we can experience that perfect "vibe state" of frictionless problem-solving.

If you're still manually typing WinDBG commands and squinting at memory dumps in 2025, you're not just missing out on productivity - you're missing out on a fundamentally more enjoyable way to work.

Try it. Debug it. Vibe it.

Moving to Fedora: Automating Discord Updates with Ansible

2024-11-15T00:00:00+00:00

Why, You Ask?

So, you've found yourself running Fedora and decided to install Discord, huh? Great choice - Fedora is fantastic. But then you realize Discord's tarball updates are a hassle. Every week, it's the same story: download, extract, and pray you didn't miss a step. Tedious, right?

I use the following Ansible playbook to install and update Discord on Fedora. It handles the repetitive steps and makes the setup easy to reuse on another machine.

Step 1: Understanding the Process

Discord on Linux isn't as straightforward as we'd like. Flatpak is an option, but it can be slow with updates or cause compatibility issues. For those of us who prefer the direct tarball approach, we need a way to automate the mess. With Ansible, we can ensure Discord is always up-to-date with just one command. No more hunting for the latest download link or worrying about cleaning up old versions.

Step 2: The Playbook

Here's an Ansible playbook to make your life easier. It handles everything - downloading the tarball, extracting it to the proper location, and cleaning up afterward.

---
- name: Install and Update Discord on Fedora 41 using Ansible
  hosts: localhost
  become: true
  tasks:
    - name: Ensure /usr/share/discord is removed if it exists
      file:
        path: /usr/share/discord
        state: absent

    - name: Download Discord tarball
      get_url:
        url: "https://discord.com/api/download/stable?platform=linux&format=tar.gz"
        dest: "/tmp/discord.tar.gz"
        mode: "0644"

    - name: Create /usr/share/discord directory
      file:
        path: /usr/share/discord
        state: directory
        mode: "0755"

    - name: Extract Discord tarball to /usr/share/discord
      unarchive:
        src: "/tmp/discord.tar.gz"
        dest: "/usr/share/discord/"
        remote_src: true
        extra_opts: ["--strip-components=1"]
      args:
        creates: "/usr/share/discord/discord"

    - name: Clean up temporary files
      file:
        path: "/tmp/discord.tar.gz"
        state: absent

Step 3: What This Playbook Does

Step 1: If Discord is already installed, it removes the existing files to prevent conflicts.
Step 2: It downloads the latest stable Discord tarball directly from the official API.
Step 3: Creates the required directory at /usr/share/discord.
Step 4: Extracts the tarball into /usr/share/discord, stripping unnecessary folder components.
Step 5: Cleans up temporary files, leaving your system tidy.

A Note About Bash Aliases

If you're like me and love shortcuts, consider adding a bash alias to streamline running the playbook. This way, updating Discord becomes as simple as typing a single command. Here's how you can set it up:

cat ~/.bashrc.d/alias.sh
alias ansible-venv=". ~/repos/ansible/.venv/bin/activate"
alias update-discord="ansible-venv && ansible-playbook ~/repos/ansible/update-discord.yml --connection=local -K"

With this in place:

ansible-venv activates your virtual environment for Ansible.
update-discord runs the playbook with local connection and prompts for sudo permissions when needed.

Now, keeping Discord updated is literally a one-liner. Perfect, right?

Summary

The same playbook handles both the first installation and later updates, so keeping Discord current only takes one command.

So, go ahead - run it, relax, and enjoy Fedora without the hassle. Because let's face it: managing updates manually is so last year.

Moving to Fedora: Automating PowerShell Installation with Ansible

2024-11-15T00:00:00+00:00

Why, You Ask?

I use PowerShell on Fedora for scripting and automation. Installing it manually is fine once, but it becomes repetitive across workstations, VMs, dev containers, and servers.

This Ansible playbook automates the installation and keeps the setup consistent across those environments.

Step 1: The Problem

Installing PowerShell on Fedora involves downloading Microsoft's repository package, registering it, updating the package index, and then installing the actual PowerShell package. It's fine if you're doing it once, but if you have to repeat the process on multiple systems, it quickly becomes a chore.

The solution? Use Ansible to do it for you. Write the playbook once, and it works everywhere - no matter how many machines you're dealing with.

Step 2: The Playbook

Here's the Ansible playbook that automates PowerShell installation on Fedora:

---
- name: Install PowerShell on Fedora 41 using Ansible
  hosts: localhost
  become: yes
  gather_facts: true

  tasks:
    - name: Download Microsoft repository package
      ansible.builtin.get_url:
        url: https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
        dest: /tmp/packages-microsoft-prod.rpm

    - name: Register Microsoft repository
      ansible.builtin.command:
        cmd: rpm -i /tmp/packages-microsoft-prod.rpm
      args:
        creates: /etc/yum.repos.d/microsoft-prod.repo

    - name: Remove repository package after registration
      ansible.builtin.file:
        path: /tmp/packages-microsoft-prod.rpm
        state: absent

    - name: Update package index
      ansible.builtin.dnf:
        update_cache: yes
        state: latest

    - name: Install PowerShell
      ansible.builtin.dnf:
        name: powershell
        state: present

    - name: Verify PowerShell installation
      ansible.builtin.command:
        cmd: pwsh --version
      register: pwsh_version_output

    - name: Display PowerShell version
      ansible.builtin.debug:
        msg: "Installed PowerShell version: {{ pwsh_version_output.stdout }}"

Step 3: Usage

Running this playbook is straightforward. If you're working with a virtual environment for Ansible, make sure it's activated. Then, execute the playbook locally with the following command:

ansible-playbook /path/to/install-powershell.yml --connection=local -K

Here's a quick breakdown:

ansible-playbook: Runs the playbook.
/path/to/install-powershell.yml: Path to the playbook file.
--connection=local: Executes the playbook on the local machine instead of a remote host.
-K: Prompts for sudo privileges to perform the installation.

With this command, you can easily install PowerShell on your Fedora system without worrying about missing steps.

Summary

With this playbook, installing PowerShell on a new Fedora system takes one command and produces the same setup each time.

So, the next time you're staring down the prospect of yet another manual PowerShell install, let Ansible take care of it. Because honestly, you've got better things to do.

Simplify SSH

2024-10-03T00:00:00+00:00

Why, You Ask?

I was tired of entering my SSH key passphrase every time I connected to a server. The setup below lets ssh-agent remember it for the current terminal session and also keeps host settings in one place.

It's time-consuming and frustrating. I'm tired of it.

Getting Started

So, you've got your shiny new SSH key and every time you want to connect to a server, you're greeted with that ever-familiar password prompt. Sure, typing your SSH key passphrase every time is good for security, but, come on - who wants to do that? I mean, I don't know about you, but I've got enough passwords to remember without constantly dealing with this nonsense.

Let's save ourselves some time and effort by getting the SSH agent to remember our keys for us. That way, you can just run your commands like the seasoned developer you are without worrying about the whole "password entering" thing every single time.

Step 1: Start the SSH Agent

First things first - let's get the SSH agent up and running. It's like your personal SSH butler, here to remember your key so you don't have to.

Open up your terminal and type:

eval $(ssh-agent -s)

Boom! Now the agent is running in the background, ready to hold your keys like the responsible little daemon it is.

Step 2: Add your key to the SSH Agent

Now that the agent is up, let's give it your key. You only need to do this once per session, and the agent will keep it ready for you.

ssh-add ~/.ssh/your_key

Replace your_key with the name of your private key file. Enter the passphrase once and ssh-agent will remember it for the rest of the terminal session.

Step 3: Configure your SSH setup to be even lazier (I mean efficient)

Okay, we've got the agent running and the key added, but we can take it one step further. Why not tell SSH exactly what key to use for which server, so you never have to worry about it picking the wrong one?

To do this, we're going to set up a ~/.ssh/config file. If you don't have this file yet, don't worry - it's as easy as creating it:

touch ~/.ssh/config

Now, crack open that file with your favorite text editor and set things up like this:

Host your-server-alias
    HostName your.server.com
    User your-username
    IdentityFile ~/.ssh/your_key
    IdentitiesOnly yes

Breaking it down

Host: You can use any alias here that makes sense to you. This is what you'll type when you want to connect to this server.
HostName: The actual domain or IP address of the server.
User: Your username on that server, so you do not have to specify it each time.
IdentityFile: The path to your SSH private key.
IdentitiesOnly yes: Tells SSH to use only this key, rather than trying every key it can find in the agent (which is how you avoid that annoying "user mismatch" issue).

Step 4: Create a wrapper script for SSH Agent control

Alright, you want control over when your SSH agent starts up - totally understandable! Instead of running the agent automatically on login (which might feel a bit too autonomous), we'll create a neat little wrapper script. You can trigger it whenever you feel like starting the agent and adding your SSH key for the session.

Here's how to set that up.

Create the wrapper script

Let's create a script that starts the SSH agent, adds your key, and gives you control over when it runs. We'll call this script init-ssh, and we'll stick it somewhere like /usr/local/bin so it's available from anywhere in your terminal.

Create the script: Open your terminal and create the init-ssh script:
```
sudo nano /usr/local/bin/init-ssh
```

Add the script content: Paste the following content into the file:

#!/bin/bash

# Start the SSH agent
eval $(ssh-agent -s)

# Add the key to the agent
ssh-add ~/.ssh/your_key

# Optional: Display agent status for peace of mind
ssh-add -l

Make the script executable: Give the script executable permissions:
```
sudo chmod +x /usr/local/bin/init-ssh
```

How to use the script

Whenever you want to start your SSH agent for a session, just run:

. init-ssh

This will start the agent, add your key, and show you a list of the keys currently loaded in the agent. You've got full control - start the agent when you want, stop it when you're done, and enjoy a password-free SSH experience for the duration of that session.

Optional: Stopping the SSH Agent

If you want to stop the SSH agent after you're done with it, you can either let it die when you close your terminal or manually kill it with:

eval $(ssh-agent -k)

That way, you get all the convenience of an SSH agent when you need it, without it running indefinitely in the background. You're now in complete control of your SSH setup, and you can keep things secure and efficient, exactly the way you like it.

Happy SSH'ing!

Simplify Elasticsearch and Kibana Installation

2024-04-24T00:00:00+00:00

Why, You Ask?

Setting up Elasticsearch and Kibana involves the same steps each time: update the system, configure repositories, install packages, and apply the initial configuration. I wrote a script to automate that work and make the setup reusable.

It's time-consuming and frustrating. I'm tired of it.

Automating the Setup

This Bash script installs Elasticsearch and Kibana as a single-node cluster. I use it when I need a small, repeatable setup without adding another configuration tool.

Why Choose a Bash Script?

I chose Bash instead of Ansible because the script also works well with cloud-init and inside Docker environments. It has no extra tooling requirements and is easy to copy to a new machine.

Building the Script: A Step-by-Step Guide

Let's walk through the crafting of the script that automates setting up Elasticsearch and Kibana. Here's how I pieced it together, one step at a time:

Checking for Superuser Privileges The script needs administrative access, so it starts by checking for root privileges.

if [ "$(id -u)" != "0" ]; then
   echo "This script must be run as root" 1>&2
   exit 1
fi

Updating the System and Installing Essential Packages Updating the system first helps avoid installation problems caused by outdated packages.

apt update
apt install -y apt-transport-https gnupg curl jq

Adding the Elasticsearch Repository Getting this right is like picking the perfect ingredients for a master chef recipe - it ensures the rest of the meal turns out just right.
Installing Elasticsearch and Kibana Next, the script installs Elasticsearch and Kibana.
Configuring and Starting Services The plot thickens! Setting up the services and getting them running is like reaching the climax of our story - where all elements come together to unveil the full potential of our setup.

Rather than churn out another cookie-cutter guide on setting up Elasticsearch and Kibana, you can view the complete script here. However, I do want to emphasize the initial configuration process involving enrollment tokens and security settings. I've automated these aspects because, let's face it, I've read too many guides that suggest just turning off security for the sake of simplicity. That's not my style - I'd rather keep things secure automatically. It's not rocket science, but it sure is critical. Why simplify by compromising security when you can automate it effectively, right?

This approach ensures you get the functionality you need without the hassle of manual setup or the risks of disabled security.

Perfecting the Automation: Securing and Finalizing the Setup

The final part configures security and leaves both services ready to use.

Broadcasting the Good News First things first, let's make sure any user logging into the system knows what's been accomplished:

echo -e "=== init-vm.sh: Initial ===" >> /etc/motd
echo -e "[> Elasticsearch 'elastic' password: $ELASTIC_PASSWORD" >> /etc/motd
echo -e "[> Test instance with 'curl -k -X GET https://elastic:$ELASTIC_PASSWORD@localhost:9200'" >> /etc/motd
echo -e "=== init-vm.sh: Get started ===" >> /etc/motd
echo -e "[> Reset 'elastic' password with '/usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic'." >> /etc/motd

Here, we're updating the message of the day (MOTD) file to ensure anyone who logs in is immediately informed about how to interact with Elasticsearch and what steps to take next. It's like leaving a note on the fridge - impossible to ignore and incredibly helpful.

Decoding the Secrets Automation isn't just about doing things without human intervention; it's also about doing them securely and wisely:

# Because who likes doing setup manually, right?
decoded_token=$(echo $KIBANA_ENROLLMENT_TOKEN | base64 --decode)
address=$(echo $decoded_token | jq -r '.adr[0]')
fingerprint=$(echo $decoded_token | jq -r '.fgr')
api_key=$(echo $decoded_token | jq -r '.key')

Decoding the enrollment token reveals the essential elements needed to securely configure Kibana: the address, fingerprint, and API key.

Harnessing Version and Build Information Knowing exactly which version and build of Kibana you're working with is required for the API, so let's get that:

ver=$(jq -r '.version' /usr/share/kibana/package.json)
build=$(jq -r '.build.number' /usr/share/kibana/package.json)

Re-encoding and Verification Secrecy is paramount, and so is verification. Here's how we handle both:

encoded_api_key=$(echo -n $api_key | base64)
output=$(sudo /usr/share/kibana/bin/kibana-verification-code)
verification_code=$(echo $output | awk -F": " '{print $2}' | sed 's/ //g')

The API key needs to be re-encoded to maintain security, and we also extract a verification code necessary for the next step - enrolling Kibana.

The Final Act: Enrolling Kibana

And now, the final piece of our automation puzzle:

curl -k -v -X POST "http://localhost:5601/internal/interactive_setup/enroll" \
     -H "Accept: */*" \
     -H "Content-Type: application/json" \
     -H "Host: localhost:5601" \
     -H "Origin: http://localhost:5601" \
     -H "Referer: http://localhost:5601/" \
     -H "kbn-build-number: $build" \
     -H "kbn-version: $ver" \
     -H "x-elastic-internal-origin: Kibana" \
     -H "x-kbn-context: %7B%22type%22%3A%22application%22%2C%22name%22%3A%22interactiveSetup%22%2C%22url%22%3A%22%2F%22%7D" \
     -d '{"hosts":["https://'$address'"],"apiKey":"'$encoded_api_key'","caFingerprint":"'$fingerprint'","code":"'$verification_code'"}'

This curl command not only sends all the needed parameters to Kibana for configuration but also uses the verification code to ensure that the setup is both authorized and secure. It's akin to dotting the i's and crossing the t's in our setup script.

Summary

The script turns a fresh system into a secured, working Elasticsearch and Kibana installation. Feel free to adapt it to your own environment.

Check out the complete script here:

init-elastic-search-kibana-vm.sh

Happy automating, and here's to many insightful data explorations!

P.S.: This script is tailored for automating development environments. Remember, a single-node cluster isn’t suited for production use, and storing passwords in the message of the day (MOTD) file? That’s a no-go for serious deployments. 😏

Simplify Visual Studio Installation

2024-02-12T00:00:00+00:00

Why, You Ask?

Every year, like clockwork, I find myself setting up my local dev environment from scratch. And every time, it's the same old song and dance: downloading, installing, configuring.

It's time-consuming and frustrating. I'm tired of it.

Can It Be Easier?

What if setting up a new machine, rolling it back, or tweaking it could be as simple as running a build on a server? What if I told you we could apply the same principles of automation to our local setups?

Let's Find A Solution

Creating a new development environment shouldn't be a chore. It should be quick, painless, and even a little bit fun. To turn this dream into reality, I need two things: the right software and the perfect setup. That's where winget and .vsconfig come in.

With a list of essential software and some PowerShell tricks, I began to make boring tasks automatic. I picked each program, from 7Zip to Visual Studio, for its important use. But the adventure of automating everything is a story for another time.

Streamlining Visual Studio Installation

My main event? Automating Visual Studio installation. Using winget, I can install Visual Studio with just a line:

winget install -e --id Microsoft.VisualStudio.2022.Enterprise --silent

But I didn't stop there. With the --override flag, I tailored the installation to include specific workloads, like this:

winget install -e --id Microsoft.VisualStudio.2022.Enterprise --silent --override "--wait --quiet --addProductLang En-us --config C:\vs2022.vsconfig"

This method sets up Visual Studio with the workload I need without having to manually select each package.

What's `.vsconfig`?

.vsconfig helps me easily replicate my development environment wherever I am. It's a JSON file that, with just a few clicks in the Visual Studio Installer, allows me to compress my environment workloads into a neat package. This approach is not only perfect for keeping build servers and personal development environments in sync with identical workloads, but it also simplifies sharing updates and changes with teammates.

Example: vs2022.vsconfig

{
  "version": "1.0",
  "components": [
    "Microsoft.VisualStudio.Component.Roslyn.Compiler",
    "Microsoft.Component.MSBuild",
    "Microsoft.VisualStudio.Component.Roslyn.LanguageServices",
    "Microsoft.VisualStudio.Component.SQL.LocalDB.Runtime",
    "Microsoft.VisualStudio.Component.CoreEditor",
    "Microsoft.VisualStudio.Workload.CoreEditor",
    "Microsoft.VisualStudio.Component.TypeScript.TSServer",
    "Microsoft.VisualStudio.ComponentGroup.WebToolsExtensions",
    "Microsoft.VisualStudio.Component.JavaScript.TypeScript",
    "Microsoft.VisualStudio.Component.TextTemplating",
    "Microsoft.VisualStudio.Component.NuGet",
    "Microsoft.VisualStudio.Component.IntelliTrace.FrontEnd",
    "Microsoft.VisualStudio.Component.Debugger.JustInTime",
    "Component.Microsoft.VisualStudio.LiveShare.2022",
    "Microsoft.VisualStudio.Component.IntelliCode",
    "Microsoft.VisualStudio.Component.ClassDesigner",
    "Microsoft.VisualStudio.Component.GraphDocument",
    "Microsoft.VisualStudio.Component.CodeMap",
    "Microsoft.VisualStudio.Component.VC.CoreIde",
    "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
    "Microsoft.VisualStudio.Component.Graphics.Tools",
    "Microsoft.VisualStudio.Component.VC.DiagnosticTools",
    "Microsoft.VisualStudio.Component.Windows11SDK.22621",
    "Microsoft.VisualStudio.Component.VC.ATL",
    "Microsoft.VisualStudio.Component.SecurityIssueAnalysis",
    "Microsoft.VisualStudio.ComponentGroup.ArchitectureTools.Native",
    "Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
    "Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
    "Microsoft.VisualStudio.Component.Windows11Sdk.WindowsPerformanceToolkit",
    "Microsoft.VisualStudio.Component.CppBuildInsights",
    "Microsoft.VisualStudio.ComponentGroup.WebToolsExtensions.CMake",
    "Microsoft.VisualStudio.Component.VC.CMake.Project",
    "Microsoft.VisualStudio.Component.VC.TestAdapterForBoostTest",
    "Microsoft.VisualStudio.Component.VC.TestAdapterForGoogleTest",
    "Microsoft.VisualStudio.Component.VC.ASAN",
    "Microsoft.VisualStudio.Component.Vcpkg",
    "Microsoft.VisualStudio.Component.VC.Tools.ARM64EC",
    "Microsoft.VisualStudio.Workload.NativeDesktop",
    "Microsoft.VisualStudio.Component.VC.Runtimes.ARM64EC.Spectre"
  ]
}

You can create a .vsconfig file with these easy steps:

Launch the Visual Studio Installer and choose to modify your setup.
Hit More and then select the option to Export your settings into a .vsconfig file.

That's it!

Why Bother With All This?

I'm all about making life easier, not harder. Thanks to winget and Visual Studio's .vsconfig, what used to eat up a lot of time now takes no time at all.

Setting up a fresh development environment is now a piece of cake - and I mean the kind of delicious cake you can buy ready-made but tastes as good as anything you'd bake yourself. So here's to spending less time on setup and more on the fun stuff: coding.

Blog Motivation

2024-02-10T00:00:00+00:00

Why, You Ask?

We all have those annoying little tasks that pop up a few times a year. They're too rare to make fixing them a big deal but happen just enough to be really annoying. Think about setting up a new laptop, sorting out files, refactor that NULL to nullptr or those updates that take forever. It eats up time and patience. I'm tired of it.

Changing Things Up

I started this blog not just to talk tech but to tackle these annoying moments head-on. My goal? To stop saying "it's not worth fixing" and start finding ways to make these tasks less of a headache. Even those things we do once in a blue moon? Yeah, I want to automate those too. And I'll share every step right here.

This blog is my playground and my megaphone. It's where I try out new ideas to make life easier and then shout out what works. Each post starts with my cheeky

"Why, You Ask?"

and always circles back to me spilling the beans on how I truly feel, which usually is

"I'm tired of it."

It's my unique approach, sprinkled with a dash of sarcasm, as I navigate through the mayhem, assuring you that behind every vent, there's a solid reason and, believe it or not, a solution waiting to be uncovered.

Making things easier is only part of it. I also want to share useful ideas, opinions, and the occasional rant. When I find a good way to avoid repetitive work, I'll write it down here so others can use it too.

Come Along for the Ride

If that sounds familiar, have a look around and share your own ideas. None of us should spend more time on repetitive work than necessary.

Welcome to my quest for a smoother, simpler tech life. Here's to less frustration and more time doing what we love. Let's kick those annoying tasks to the curb.

svnscha - automation

AI Meets WinDBG: A Different Way to Analyze Crashes

Old Meets New: Bringing Crash Analysis into 2025

When Inspiration Strikes

See It In Action: AI-Powered Crash Analysis

Video 1: Crash Analysis and Automated Bugfix

Video 2: Automated Crash Dump Analysis of multiple crash dump files

How can this help the industry?

How did I build this?

Understanding Model Context Protocol Servers

Why MCP Instead of LanguageModelTool API?

The MCP-WinDBG Project

What Does This Mean In Practice?

How It Works

Getting Started With mcp-windbg

The Human Touch Still Matters

Join The Experience

The Magic Is In The Flow

Summary

Moving to Fedora: Automating Discord Updates with Ansible

Why, You Ask?

Step 1: Understanding the Process

Step 2: The Playbook

Step 3: What This Playbook Does

A Note About Bash Aliases

Summary

Moving to Fedora: Automating PowerShell Installation with Ansible

Why, You Ask?

Step 1: The Problem

Step 2: The Playbook

Step 3: Usage

Summary

Simplify SSH

Why, You Ask?

Getting Started

Step 1: Start the SSH Agent

Step 2: Add your key to the SSH Agent

Step 3: Configure your SSH setup to be even lazier (I mean efficient)

Breaking it down

Step 4: Create a wrapper script for SSH Agent control

Create the wrapper script

How to use the script

Optional: Stopping the SSH Agent

Simplify Elasticsearch and Kibana Installation

Why, You Ask?

Automating the Setup

Why Choose a Bash Script?

Building the Script: A Step-by-Step Guide

Perfecting the Automation: Securing and Finalizing the Setup

The Final Act: Enrolling Kibana

Summary

Simplify Visual Studio Installation

Why, You Ask?

Can It Be Easier?

Let's Find A Solution

Streamlining Visual Studio Installation

What's .vsconfig?

Why Bother With All This?

Blog Motivation

Why, You Ask?

Changing Things Up

Why I Share

Sharing What I Learn

Come Along for the Ride

What's `.vsconfig`?