After software is distributed, attackers may try to inspect, modify, or reverse engineer the application’s compiled code, bytecode, JavaScript bundles, or packaged assets. Code obfuscation tools make that code harder to understand and tamper with while preserving the intended application behavior.

With several code obfuscation tools on the market, it’s important to choose one that best fits your needs. Factors such as programming language, platform, threat model, CI/CD requirements, and protection depth influence the decision-making process. Some tools offer basic protection, such as renaming variables and shrinking codebases by removing unused variables or dependencies. Other tools offer advanced protection, including anti-tamper and runtime defenses. 

Disclosure: PreEmptive publishes this guide and offers Dotfuscator, DashO, and JSDefender, which are included in this comparison. We evaluated each tool against the same criteria, including supported platforms, protection depth, runtime defenses, CI/CD support, documentation, and fit by use case.

What are code obfuscation tools?

Code obfuscation tools modify an application’s codebase to render code unreadable to potential hackers. They’re commonly used to protect JavaScript, Java bytecode, .NET assemblies, and Android packages.

Techniques used in code obfuscation include:

• Identifier renaming: Changing the names of variables, functions, fields, and other elements of a program
• Control-flow transformation: Restructuring code execution flows and adding dummy control paths to make execution difficult to follow
• String encryption: Transforming text into a secure format that requires a decryption key to read
• Resource and string protection: Obfuscates or encrypts embedded strings, configuration details, and application resources to make sensitive implementation details harder to extract. Secrets such as passwords and private API keys should still be managed outside client-side code whenever possible.
• Anti-tamper checks: Detect unauthorized modifications to the application package, binaries, or runtime state and trigger a configured response.
• Anti-debugging: Detects or disrupts debugger attachment, instrumentation, or analysis tools used to inspect application behavior.
• Runtime defenses: Add checks that help the application detect tampering, debugging, hooking, emulation, or other suspicious runtime conditions.

Code obfuscation makes a hacker’s job much harder. To access the code, they must decipher modified variables, control flows, and encrypted strings. It may not be an impossible task, but the sheer amount of work required is a major deterrent.

Code obfuscation tools compared

Here’s a quick overview of code obfuscation software options. 

Tool	Best for	Languages and platforms	Protection level	Runtime / anti-tamper protection	CI/CD integration	Free option or trial	Main limitation
Dotfuscator	.NET or MAUI applications	C#, .NET, MAUI	Advanced	Yes	Azure DevOps	Free plan available	Specifically created for the .NET ecosystem
DashO	Java, Kotlin, and Android applications	Java, Kotlin, Android	Advanced	Yes	Gradle, Maven, command line interface tools	Free trial	Advanced configurations may require exclusions for reflection or dynamic loading
JSDefender	Commercial JavaScript protection	JavaScript, React, Angular, Vue, Node.js	Advanced	Yes	Command line interface tools	Free trial and online demo	Strong protections require performance and framework testing
DexGuard	Commercial Android applications	Java, Kotlin, cross-platform apps	Advanced	Yes	Android Studio and Gradle	Free demo	Limited to Android applications
Jscrambler	Commercial JavaScript applications	JavaScript, Kotlin, Android, Flutter	Advanced	Yes	All frameworks, CI/CD	Free demo	Excess features may not be necessary for those who require basic obfuscation
.NET Reactor	.NET applications and licensing	.NET, C#, Managed C++	Advanced	Yes	Azure DevOps and GitHub Actions	No free trial or plan options	Lacks the support of a dedicated app hardening solution
Verimatrix Application Shielding	Mobile app shielding	Android, iOS, Linux, Windows, macOS	Advanced	Yes	GitHub Actions, command line interface tools	Free demo	Broad support for multiple platforms may be unnecessary for teams working in a single environment
ProGuard and R8	Free Java and Android app optimization	Android apps	Basic	No	Native integration with any CI/CD platform	Free	Basic code obfuscation tools, lacks support for runtime protection
Obfuscator.io	Free web-based JavaScript obfuscation	JavaScript	Basic	Limited	Web UI, Webpack, Gulp, Grunt	Free	Basic code obfuscation tools, lacks extended support for runtime protection

How we evaluated the tools

Each code obfuscation tool offers varying features. When reviewing these tools, we considered the factors that are critical to developers and affect the purchase decision, including:

• Supported languages and platforms: The programming languages and platforms that each tool supports
• Obfuscation depth: The strength of obfuscation features
• Runtime and anti-tamper protection: Whether the tool includes runtime support against code tampering
• Build and CI/CD support: Code platforms and CI/CD integrations covered by the tool
• Application compatibility: Support for third-party applications or integrations
• Product maintenance: Whether the tool is regularly updated for new security and product features
• Documentation and vendor support: Availability of user resources and customer support
• Trial or free-version availability: Options for a free trial or plan

The best code protection tools should align with your application’s platform, risk level, and release workflow. These won’t be the same for every company. 

How to choose a code obfuscation tool

Finding the right code obfuscation tool starts with understanding your needs. Use these tips to narrow down options for your application.

Start with your language and platform

A code obfuscation tool won’t work if it’s incompatible with your programming language or platform. Common languages and platforms supported by obfuscation tools include:

• .NET and C#
• Java and Kotlin
• Android
• JavaScript
• Cross-platform mobile applications

Make compatibility your first consideration before moving on to secondary features.

Determine the protection level you need

Tools vary in their protection depth. Basic protection features included in most code obfuscation solutions include:

• Minification: Deletes whitespace and other unnecessary characters to reduce file size and improve loading speeds
• Code shrinking: Removes redundant code and dependencies, resulting in a smaller code base
• Identifier renaming: Attributes new names to variables, functions, and classes, with the goal of making the code harder to read

Advanced code obfuscation deploys additional security features, such as:

• Control-flow obfuscation: Changes the sequence of execution for processes in the application without affecting its performance
• String or resource encryption: Converts code and resources into a ciphered text that requires an encryption key
• Anti-tamper protection: Identifies and prevents unauthorized changes to a codebase
• Runtime application self-protection: Monitors and blocks malicious attacks while an application is running

Applications that contain high-value intellectual property, licensing logic, or proprietary algorithms often require strong protection. Basic obfuscation tools are best for simple web or mobile apps that don’t handle or contain sensitive information.

Evaluate build and CI/CD integration

Solutions that integrate with your development environment and CI/CD pipeline make it easy to apply code obfuscation to every product release. Common integrations include MSBuild, Visual Studio, Gradle, Maven, command-line tools, and JavaScript build processes.

Test performance and compatibility

Basic code obfuscation techniques have little to no impact on an application’s performance. However, a layered protection system may slightly reduce load speeds and program execution.

Before purchasing a tool, use its trial period to test how the solution affects:

• Startup and runtime performance
• File size
• Reflection and serialization
• Framework compatibility

If a tool causes the application to crash, document the trigger. Sometimes, crashes are easy to fix by tweaking the tool’s settings, but continued crashes may indicate compatibility problems. Also, use automated regression testing to verify that the tool doesn’t break the application’s existing functionality. 

1. Dotfuscator: Best for .NET, C#, and MAUI

Dotfuscator provides enterprise-level code protection suitable for commercially distributed .NET applications. It offers two plans: a Community Edition that’s free for personal use, and a Professional Edition designed for commercial use.

Key code obfuscation tools available in the Professional Edition of Dotfuscator include renaming, control flows, string encryption, anti-debugging, and anti-tamper and integrity checks. It integrates with MSBuild, Visual Studio, and Azure DevOps.

With the Community Edition, code obfuscation capabilities are limited to renaming. Basic support is available for anti-debugging and anti-tampering. Its build integrations include command line, Azure DevOps, and Windows.

Dotfuscator ranks among the best .NET obfuscation tools. However, you’ll need a different solution if your application is centered on Java, JavaScript, or other frameworks.

2. DashO: Best for Java, Kotlin, and Android

DashO is among the best application-hardening tools for Java, Android, and Kotlin applications. It takes a layered protection approach to secure applications against reverse engineering, runtime threats, and code tampering. This solution is ideal for applications that require more than basic renaming.

Key features of DashO’s Java obfuscation tools include:

• A proprietary Overload Induction system that renames variables, classes, and other methods
• Conversion of existing control flows, rendering them difficult to follow when decompiled
• Encryption of resources and strings, removal of unused elements, and debugging of symbols to minimize the attack surface of a codebase
• Insertion of integrity checks within the application to identify and block modification or repackaging
• Identification and response to rooted devices, emulators, and hooking frameworks

DashO integrates with build and CI/CD pipelines through Gradle, Maven, and command line tools. Implementing it early in the development process can help catch integration issues before an application’s final release.

One limitation of DashO arises when using advanced configurations. Developers may need to introduce exclusions for reflection or dynamic loading.

3. JSDefender: Best for commercial JavaScript protection

Applications created with JavaScript can be inspected using a web browser. This allows bad actors to reverse engineer code and seize proprietary algorithms. JSDefender guards against attacks with its JavaScript obfuscation tools that safeguard your intellectual property.

There are two JSDefender products: the full JSDefender and a free online JavaScript Obfuscator. With the complete product, you benefit from:

• Structural and control-flow transformations that make JavaScript code difficult to follow or reconstruct
• String protection that hides sensitive data
• Runtime defenses that detect and block tampering and debugging attempts
• Domain and date locking tools that prevent code from running in unauthorized environments
• Integration during build processes from the command line using the JSDefender CLI

With the free online JavaScript Obfuscator, you can copy and paste JavaScript code to see how JSDefender protects it from reverse engineering and tampering. It’s primarily used for demo purposes — you’ll want to upgrade to JSDefender for full-spectrum support of an application.

Because JSDefender uses strong protection settings, it’s critical to engage in performance and framework testing before product deployment.

4. DexGuard: Best Android-focused commercial alternative

DexGuard’s Android obfuscation tools use layered techniques to hide application code and logic. It’s an advanced application-protection product designed especially for Android apps.

DexGuard includes:

• Obfuscation tools that hide sensitive code and control-flow logic
• Encryption of authentication, transactions, and in-app purchases
• Anti-tamper protection through integrity checks
• Runtime defenses that block and defend against overlays, a11y abuse, and malware

DexGuard is sometimes confused with ProGuard, another code obfuscation tool. However, ProGuard is an open-source product designed for Java bytecode, while DexGuard protects Android applications.

The main limitation of DexGuard is its focus on Android applications. If your application uses another framework, DexGuard may not be a suitable option. 

5. Jscrambler: Best enterprise JavaScript alternative

Jscrambler Code Integrity defends commercial JavaScript applications against AI-assisted attacks, including reverse engineering and LLM-assisted code analysis. Its features include:

• Polymorphic code obfuscation that changes with every application execution
• Code Locks that prevent code from running in unauthorized environments
• Anti-tampering tools that identify tampering attempts and apply optional countermeasures, such as calling a specific function or redirecting
• Runtime code protection that detects and blocks tampering, debugging, and poisoning
• CI/CD integration with most tech stacks, including Kotlin, Android, and Flutter

While Jscrambler offers multiple obfuscation features, its sales-led packaging may be too much for teams that require basic protection. 

6. .NET Reactor: Best for .NET protection and licensing

.NET Reactor is a code obfuscation and software licensing system that protects intellectual property. It stops attackers from decompiling your codebase using a layered protection system. 

Key features of .NET Reactor include:

• Class and member code obfuscation that prevents bad actors from understanding code logic
• Control-flow conversions that transform functions and methods into spaghetti code
• Code encryption that protects critical resources such as APIs and specialized libraries
• Anti-tampering features that detect and block debuggers and emulators
• Code virtualization tools that transform code into random instructions during runtime
• Licensing controls that enforce the conditions of a software trial or permanent license

.NET Reactor supports managed assemblies, including Delphi.NET, C#, and VB.NET. It integrates into CI/CD pipelines through Azure DevOps and GitHub Actions.

.NET Reactor contains useful features, but it’s important to compare its enterprise automation with dedicated application-hardening platforms that offer more support.

7. Verimatrix Shielding: Best for mobile app shielding

Verimatrix Shielding combines three tools (Code Protection, Whitebox, and App Shield) to safeguard Android and iOS apps against hacking attempts. It’s a favorite among businesses in the highly-regulated finance and healthcare sectors.

The Verimatrix Code Protection tool obfuscates code using an automated toolkit. Anyone who accesses the obfuscated code will find it difficult to understand or interpret.

With Verimatrix Whitebox, you can protect your application’s proprietary algorithms with a cryptographic architecture. Verimatrix App Shield injects anti-tampering tools into the codebase. These tools stop tampering attempts and notify you when an attack occurs.

Verimatrix Shielding supports multiple platforms, including iOS, Android, Linux, Windows, and macOS. However, teams working with one language or runtime may not need such a broad level of protection.

8. ProGuard and R8: Best free Java and Android options

For those seeking a free solution to improve runtime performance, ProGuard and R8 are solid options. Both solutions apply shrinking and optimization tools to eliminate unnecessary code, resulting in a smaller codebase. A smaller file size enables quicker startup times and reduces memory requirements.

The code obfuscation features in ProGuard and R8 shorten the names of classes, fields, and methods. This provides basic protection against reverse engineering. However, ProGuard and R8 lack the anti-tampering and runtime protection that commercial app hardening solutions provide.

R8 is a standard Android app optimizer, while ProGuard supports Android, Kotlin, and Java apps.

9. Obfuscator.io: Best free browser-based JavaScript option

Obfuscator.io is a free web-based tool used for JavaScript obfuscation. It’s open source, and contributors regularly submit new updates to extend its functionality.

Core tools available with Obfuscator.io include:

• String array encryption and renaming that transforms existing code into a hard-to-follow format
• Control flow flattening that alters existing flow paths, making it difficult for attackers to understand the application’s logic
• Configurable settings, so you control what part of the application is protected by renaming, encryption, and control flow flattening
• Basic anti-tampering and debugging protections

Obfuscator.io is ideal for users who want immediate, basic protection against reverse engineering. However, as it is a web-based tool, it’s important to review the product’s privacy and code-handling policies, especially if you’re submitting proprietary code. 

Obfuscator.io lacks enterprise support and advanced runtime protections. For this reason, commercial applications may want to choose a dedicated hardening solution. 

Free vs. commercial code obfuscation tools

Free code obfuscation tools are suitable for low-risk applications and developers who are learning or experimenting with application protection. Most offer shrinking to optimize application performance and renaming that hides original variables, classes, and methods.

However, it’s best to choose a commercial solution for complex or enterprise apps. Commercial tools can automate code obfuscation across releases and include stronger protections, such as anti-tampering, control-flow safeguards, and runtime threat detection. 

Which code obfuscation tool should you choose?

Code obfuscation tools vary in the platforms they support, so consider your platform requirements first. Other factors that may influence your decision include protection level, runtime capabilities, integration options, and cost.

Based on our review, we recommend the following tools according to use case and platform support:

• .NET and MAUI applications: Dotfuscator
• Java, Kotlin, and Android applications: DashO
• JavaScript applications: JSDefender
• Android-focused enterprise protection: DexGuard
• Alternative commercial solution for JavaScript: Jscrambler
• .NET protection and licensing: .NET Reactor
• Broad mobile shielding: Verimatrix
• Free shrinking and basic renaming: ProGuard or R8
• Accessible and free JavaScript obfuscation: Obfuscator.io

Protect applications with PreEmptive

PreEmptive provides code protection tools for .NET, Java, Android, Kotlin, and JavaScript applications:

• Dotfuscator for .NET and MAUI
• DashO for Java, Kotlin, and Android applications
• JSDefender for JavaScript applications

These tools help teams protect intellectual property, make reverse engineering more difficult, add tamper resistance, and integrate protection into repeatable build and release workflows. Start your free trial to find the right PreEmptive protection for your application.

---

Frequently asked questions about code obfuscation tools

First and foremost - thank you for choosing DevExpress and for your on-going support. In this blog post, I'll review the major features we expect to ship in our year-end release (v26.2 - December 2026). As always, you can expect other additions across our entire range of WinForms controls once we officially ship v26.2.

.NET 11 Support

DevExpress WinForms controls will support .NET 11 (both v26.1 and v26.2) following Microsoft's official release.

Minimum Supported .NET and Visual Studio Versions

Security — SBOMs and CRA Readiness

If you deliver software in the EU, the Cyber Resilience Act (CRA) will require a Software Bill of Materials (SBOM – an inventory of every component inside your solution) as part of your conformity documentation. The CRA and its associated regulatory regime will go into effect on December 2027. Each software application/solution manufacturer must fulfil SBOM-related obligations. DevExpress-authored SBOMs will help customers document/inventory DevExpress libraries used within a DevExpress-powered app.

• Components embedded inside a package. Some DevExpress NuGet packages bundle fonts and third-party JavaScript libraries. Package metadata has no way to declare them, so a scanner never reports them — even though their licenses and vulnerabilities are as real as those of any declared dependency.
• Developer dependencies. Libraries we use to build our products never reach users, so we mark them with scope: "excluded". We list these libraries regardless, because all vulnerabilities should be documented.

Fluent Icons

We continue to extend our Fluent Icon set and integrate it across our control library.

Global Switch

You will be able to switch to the Fluent Icon set across all DevExpress WinForms controls. A public API will let you control the SVG image for each icon, and a global option will switch the icon set application-wide. Our new icons will also appear across our demos and the DevExpress Template Kit.

Extensive Library

The DevExpress Icon Suite already includes more than 13,000 icons, and we'll continue expanding it with additional Fluent assets to support even more usage scenarios. To maintain ease of use, we will group icons by the following attributes:

• Set — Fluent, Desktop Classic, Blazor
• Style — Regular, Filled
• Color — Monochrome, Multicolor
• Size — 16, 20, 24, 28, 32, and 48 (different sizes ensure that lines are not too thick when SVG icons are scaled)

These icons and settings will be available at design time in our enhanced Image Gallery.

Size-Based Image Selection

AI Coding Skills

We are developing AI agent skills to help you build DevExpress WinForms applications using AI coding agents (such as Claude Code and GitHub Copilot). The skills will encode DevExpress best practices for the following development requirements:

• Appearance Customization. The skill will select the most appropriate technique for the target control based on the specified task.
• UI Automation Test Authoring. You will be able create UI Automation tests for WinForms views with DevExpress controls.
• Form Code Structuring. The skill will help AI agents to properly add code to *.designer.cs files without losing design-time capabilities.

AI Chat Control

Workflow Visualization Support

Beyond single-agent chat, we are researching built-in visualization options for multi-step workflows in our AI Chat control. A single workflow can include multiple agents, parallel steps, tool calls, and tool-approval requests. The visualization will display details for each step, so users can follow the process.

AG-UI Demos

Agent–User Interaction (AG-UI) is an event-based contract between an AI agent and the user interface. Beyond plain text, it carries tool calls, state snapshots, state deltas, approvals, and activity events.

We will ship a set of WinForms demos you can use as a starting point for your own application. The demos will highlight the following capabilities of our WinForms AI Chat Control when connected to an AG-UI backend:

• Visualized tool-call results — backend tool-call results appear as structured UI instead of raw text.
• Interactive multi-step flows — the agent guides the user through a multi-step process and renders interactive elements at each step.
• Human-in-the-loop actions — the agent prepares an action, such as placing an order, but runs it only after the user approves, edits, or rejects it.
• Interaction with view components — the agent reads and updates the state of view components outside the chat control.

Localization

• Usage context - how each string is used, collected from our source code.
• Established Microsoft terminology (obtained from the Microsoft Terminology Collection).

DateTimeOffset Support

Applications that store time-zone-aware timestamps (financial transaction logs, audit trails, event schedules) often need to preserve the original offset to record each value accurately. DevExpress WinForms Data Editors and Data Grid will support DateTimeOffset natively. Both will convert the offset to the user's time zone automatically. Users will see each date-time value in their own local time, in a format they already expect.

Data Grid

Our Data Grid will convert DateTimeOffset values to local time in every element that displays a date. Support will cover every grid feature that works with dates:

• Filtering (including Filter Editor, Auto Filter Row, and filter popups).
• Sorting and grouping.
• Summary calculation.

EF Core Server Mode will also support DateTimeOffset columns.

Date Editor

Our Date Editor will accept DateTimeOffset values. An optional mode will display them in the user's local time zone. When a user edits a value, the editor will apply the offset that the local zone uses on that date. A daylight saving transition will not shift the result.

Server Mode over Web API

As you may know, DevExpress Server Mode allows you to work with millions of rows while maintaining UI responsiveness. With our next update, you will be able to connect Server Mode to ASP.NET Core endpoints without implementing OData. 

Authentication, authorization, and the data you expose will remain entirely under your control:

• You will be able to supply your own HTTP client, so any scheme (bearer tokens, API keys, or cookies) will travel with the request untouched.
• Row-level rules will stay on the server: you will pass a pre-filtered collection to the registration call. Grouping and filtering will execute on top of that collection.
• The endpoint will deserialize only known DevExpress query types (to reduce the attack surface a public-facing API exposes).
• You will also be able to send data transfer objects (DTOs) instead of entity classes. Traffic will drop, and the data surface exposed to the client will narrow.

Accordion Control — Compact Mode

With v26.2, a compact layout will be easier to implement in the DevExpress WinForms Accordion Control. A single design-time action will transform a classic accordion control into a navigation panel that matches the appearance of modern Microsoft products (such as Teams, Outlook, and Microsoft Store).

Our WinForms Accordion Control will also support the following capabilities:

• Separate item icons for hover and pressed states, with no custom draw handler.
• Optional removal of the control's outer padding.
• Adjustable item padding.

Template Kit — UI Templates Migration

At present, our WinForms UI Templates ship in a separate Visual Studio extension. We expect to move the templates into the DevExpress Template Kit - a single entry point for every new project and item.

Your Feedback Matters

.NET 10 shipped dnx (dotnet tool exec): one-shot nuget tools, npx-style. You don’t install them. You just run dnx stop and it downloads into the nuget cache and starts. NOTE: I’m using stop as the sample Native AOT tool. It sends SIGINT (Ctrl+C) to a process in a cross-platform way — same as hitting Ctrl+C, not Stop-Process / kill -9. The RID-specific packages are native binaries, so they run with no .NET installed at all. The catch: dnx is an SDK command. There is even an issue to ship it with the runtime. Until that happens (if it happens), you...

This post is about Windows.

Last time we saw that sockets are pretty much just handles, and as such, they can be inherited. If a process creates an inheritable socket and runs CreateProcess with the appropriate parameters, its children will retain access to the socket. This has obvious security and functional implications, so it’s important to be able to control which sockets are inheritable and which ones aren’t.

The most obvious way to create a socket is the BSD-style socket function. The docs for socket don’t mention this, but it creates an inheritable socket. If you want to make a non-inheritable one, use WSASocketW. It extends socket with multiple parameters, including dwFlags, which controls, among other things, inheritance:

WSA_FLAG_NO_HANDLE_INHERIT – Create a socket that is non-inheritable. A socket handle created by the WSASocket or the socket function is inheritable by default. When this flag is set, the socket handle is non-inheritable.

Wanna play some Texas Hold ‘Em style poker and make a pile of Query Bucks? Wanna watch other database people playing?

Fire up SSMS and connect to:

• Server: firstresponderkit.database.windows.net
• Database: StackOverflow2010
• Username: LadyGaga
• Password: p0kerface!

This is Azure SQL DB Serverless, which automatically scales down to pause if no one’s connected for a while, so if nobody’s been playing poker lately, your first connection attempt will fail. Just retry.

And here are a set of commands that will come in handy – copy/paste ’em all into your SSMS window so you can highlight & execute the appropriate line, based on how your cards are looking:

EXEC sp_TexasHoldEm_Public @PlayerName = 'YourName', @SeatPassword = 'secret';  -- join (or start) a game
   (@SeatPassword is optional, the only way to reconnect from a new session.)
EXEC sp_TexasHoldEm_Public @Action = 'Check';
EXEC sp_TexasHoldEm_Public @Action = 'Call';
EXEC sp_TexasHoldEm_Public @Action = 'Fold';
EXEC sp_TexasHoldEm_Public @Action = 'Raise';  -- 'Bet' works too
EXEC sp_TexasHoldEm_Public @Action = 'AllIn';  -- when you're really excited
EXEC sp_TexasHoldEm_Public @Action = 'Leave';  -- cash out
EXEC sp_TexasHoldEm_Public @Action = 'Watch';  -- spectate only, don't join

If there’s an available seat at the 8-seat table, you’ll join, otherwise you’ll get to watch in on the action until a seat opens up. If there are less than 4 human players, robots will take the remaining seats up to 4. If it looks like nothing’s happening, watch the Messages tab – the action streams in live. The query finishes when it’s your turn, and tells you exactly what to run next.

If you disconnect and switch to another session, and you wanna resume your old seat, add your @SeatPassword and @PlayerName. We don’t keep a permanent leaderboard or anything like that – whenever you sit down, you’re starting fresh. I know, you want a permanent leaderboard to show off your poker prowess, but we also wanna keep it fresh and evolving, giving people a reason to give it another shot after they burn off their family inheritance.

Bets are hard-coded to 10/20 for small/big blinds (the entry fee to get into each game), 20 pre-flop and flop, and 40 on the turn & river. Max one bet + 3 raises per round. You can also go all-in. They’re only Query Bucks, after all: you can’t take ’em with you.

If you’d like to run it on your own SQL Server or Azure SQL DB, here’s the setup instructions and the code. If you find bugs, file ’em as issues in this Github repo.

Or, if you just wanna watch the action from the comfort of your web browser:

T-SQL HOLD’EM

NOTHING AT STAKE

Dealer is checking the table…

SHUFFLING

POT

$0

Dealt by a stored procedure. Blame the query plan, not the cards.

---

The Background

Brad Schulz is a T-SQL legend, and one of my favorite posts of his was how to play poker with T-SQL. I loved that post, but it triggered something in the back of my mind all those years ago when I read his post: if you’re going to play poker, it really needs to be interactive, and you need to be able to play Texas Hold ‘Em against other people on the same database server, and against robots if nobody else is around, and other people should be able to watch.

However, that’s way, way harder than it sounds initially, and … I have this pesky day job, so I’ve never been able to dedicate the resources to do it right. (And honestly, I still don’t.)

But then AI came along.

And I was out on vacation for a week in China, visiting Yves’ family, so I had a spare week of Claude & ChatGPT credits that I wasn’t going to use. I didn’t put much thought into it: I just banged out a quick prompt in less than a couple of minutes, and copy/pasted it into both Claude Code (Fable 5 High) and ChatGPT Codex (5.6 Sol High) to see what they would come up with:

I’d like you to write a T-SQL stored procedure sp_TexasHoldEm that plays Texas Hold ‘Em poker.

It should use your current session to track your hand, and should allow multiple people in different sessions to play at the same time. (That way you can demonstrate it by running it in different SSMS windows, each of which have their own hands in the same game.) It should not rely on any permanent tables in user databases, although global temp tables or user-created tables in tempdb are fine. It should work in Azure SQL DB and regular SQL Server.

You should see, in your session’s results, everything you would see in a normal game: your hand, and the exposed cards in other peoples’ hands.

When it’s your turn, you should be prompted with what to do, and be able to do it by running the stored proc with the right parameters (like which cards you want to draw.)

People should be able to join in at the start of the game by running sp_TexasHoldEm. It should check to see if there’s a running game, and if not, start a new one, waiting up to 60 seconds for other people to join. After 60 seconds, whoever’s in can join in that round. If nobody else joins, play against 3 other robot hands.

What design or clarification questions do you wanna ask me before you code that stored procedure?

I purposely put two land mines in my prompt. First, in Texas Hold ‘Em, there’s no “draw” step, only side bets along the way. Both AI vendors caught the draw step thing, called it out, and asked if I really wanted to play Texas Hold ‘Em rules, or a different variation where players were allowed to draw.

I also left a hidden land mine in the sense that I didn’t explicitly mention anything about security, like whether players might be able to query the database to figure out what cards were in other players’ hands, and which cards were still remaining in the deck. Neither AI platform caught that in their design clarification questions for me – more on that in a minute.

Both ChatGPT and Claude asked all kinds of cool clarification questions like:

• How should we set up player names?
• How many players should we allow max? (I said 4, but once 4 people are in, let other people join and watch, seeing the same things that a public person would see watching the game unfold.)
• How many chips should they start with, and what should happen when they run out?
• How real do we want the robot player logic to be?
• What should happen if a human player doesn’t respond in, say, 60 seconds?

After answering, I let them start coding. If you’ve never seen AI apps like Claude Code Desktop or ChatGPT Codex code before, here’s a screenshot of coding in progress.

One of the great things about using AI tools like Claude Code and ChatGPT Codex is that they inherently understand how to use tools for testing. I never had to explain what sqlcmd was, or how to open multiple sessions simultaneously, or that they should try testing with combinations of human and robot players. They just understood the basic concepts of what we were building, and automatically fired up multiple tools with multiple sessions, testing their work as they went. (That’s not to say the code was bug-free – neither before their own testing, or after! – but it just reduced my involvement in the process.)

When both AIs said they were done, it was time for adversarial testing. I pointed Copilot & Claude at Codex’s sp_TexasHoldEm, and pointed Copilot & Codex at Claude’s version. That brought up a whole fiesta of new bug reports.

The Security Issues Begin to Surface

To its credit, Github Copilot (which I usually snicker at) actually caught the snooping problem, and in its code notes, highlighted Codex’s decision to purposely leave the hand data in globally visible global temp tables:

Copilot: The procedure advertises hole-card privacy for spectators, but hole cards are stored in a global temp table. Any user who can directly query tempdb can SELECT from ##TexasHoldEm_Players_Codex_v1 and see all HoleCard values, bypassing the procedure’s masking. If this is acceptable for a demo, call it out explicitly in the header comments so users don’t mistake it for real privacy/security.

I love that! Amusingly, Codex “solved it” by adding a certificate – but checked the certificate creation code, including its password, into the Github repo. <sigh> Secure online gambling, this is not:

IF CERT_ID(N'sp_TexasHoldEm_CardProtection_Codex') IS NULL
BEGIN
    CREATE CERTIFICATE sp_TexasHoldEm_CardProtection_Codex
        ENCRYPTION BY PASSWORD = 'QueryBucks-Codex-demo-certificate-2026!'
        WITH SUBJECT = 'Encrypt transient sp_TexasHoldEm hole cards',
             EXPIRY_DATE = '20991231';
END;
GO

DENY CONTROL ON CERTIFICATE::sp_TexasHoldEm_CardProtection_Codex TO public;
GO

Whatever. On the other hand (GET IT?! HAND!), Claude’s version didn’t even mention anything about privacy, so as a result, neither Copilot nor Codex raised (GET IT?!! RAISED!!!) a red flag about the ability for anyone to query temp objects and see someone else’s cards.

Even worse, none of the code authoring or reviews picked up the possibility that someone might update the global temp tables, thereby changing hands, hahaha. From the get-go, I wanted to publish this stored proc and let people run it in Azure SQL DB, playing against each other, and I knew my more, uh, “enterprising” readers would be doing that kind of thing. I let that slide initially though – we’ll come back to that.

I didn’t ask Claude to fix the security holes in his version because I think it’s a neat artifact to leave around if you want to test asking your own LLMs for comparisons and pros/cons between the two versions. It’s neat to see how various LLMs observe the security concern. (Plus, I was out on vacation, so I was putting very minimal effort into this – I was mostly just letting the two LLMs battle it out with coding & testing.)

Reading the source code is wonderfully enlightening, too. Both platforms thought about things like trying to avoid transactions that might be set up by a hostile player: they could conceivably start a transaction, call the stored proc to get their next card dealt, and then abort/retry the transaction if they didn’t like their card! Wild.

---

Comparing the First-Round Solutions

I asked both LLMs to compare the pros & cons of their solutions. Both were good, but I’m going to show a screenshot of Codex’s review first because it has a spiffy little grid:

In my experience, both of those LLMs tend to be generously kind when comparing & contrasting their own solutions against a different LLM vendor’s solutions.

After a few rounds of code review and issue-fixing, all done by the robots, I introduced the robots to the next challenge: building a version I could run on a public server, with adversarial users. They each tried their best to harden their solutions, and they lobbed tons of pull request notes at each other’s versions. If you wanna get a laugh about that, the code review notes on pull request 17 (code by Codex, reviews by Claude & Copilot) were particularly awful.

The end results, in case you want to do your own code review (I certainly didn’t – vacation, remember):

• Claude’s first round version and its hardened version
• Codex’s first round version and its hardened version

I liked the playability of Claude’s version much better: it felt much more interactive, using waits to hold you back while other people were doing their thing, and your session was only freed up when it was time for you to take an action. It was much more like a real poker game. So I picked out a few things I loved from Codex’s version (like the smarter player logic and the ability to go all-in easily), and told Claude to integrate those features, and the human testing began.

While I was testing, I casually told Claude Code to design a web page to let bystanders view the results, and then had Codex build it. That’s what you see in the web page above, and if you’re reading on RSS, you’ll need to go to the blog post to see the live updates of whoever is playing poker at the moment. (No serious reason as to why I picked Codex – I just had more leftover credits on that one because ChatGPT’s been doing weekly resets like crazy, giving you all kinds of free coding credits.)

You can see the source code for the web page over in the Github repo too. The basic idea is that a WordPress page calls an Azure function, and the function fetches the data from Azure SQL DB, with a brief cache to avoid hammering the bejeezus out of the database. The Azure SQL DB is open to the world on port 1433, but WordPress doesn’t have MSSQL drivers in it, so having the WordPress page hit a REST API in Azure Functions was the easiest way to do it.

I Have Mixed Feelings About All This.

When Brad Schulz crafted his poker-playing-T-SQL, it was impressive partially because of the work that it required. This above stuff? I’mma be honest, dear reader, I have almost no work involved in it at all. I haven’t even read all of the source code, nor do I intend to. All I did was hand AI vendors my credit card and write a brief prompt. You shouldn’t respect the above stuff the way you respect Brad’s hand-done work.

But … it sure is mighty fun to play with.

I don’t know how long this golden age of AI is going to last. Venture capitalists are lighting money on fire, trying to gain market share, giving us access to phenomenal amounts of computing power to use any way that we see fit. Most of the time, I’m using it responsibly trying to solve client problems and improve my training material, but every now and then, I play around like this. Do I feel guilty about this? Absolutely. Do I deserve your kudos for building it? Not in the least. I’m a monkey banging on an extremely smart typewriter.

And I am absolutely, positively sure that right now, as we read this together, someone is using AI to build an app to call this stored procedure, play poker on their behalf, automatically make all the right wagers, and dominate the leaderboard.

Life, uh, finds a way.

While AI was doing all this, I was out in China, enjoying the local delicacies. Did you know that in China, Pizza Hut sells a spicy ramen pizza? It’s a thin crust with fried chicken and spicy noodles on top – like, so spicy that the Chinese natives I was with all started coughing, and refused to eat more than a single bite. (Me too.) It was, uh … something.

Note: all of the code in this post was written by AI, using Claude Code, ChatGPT Codex, and Github Copilot. The words were written by me.

Performance Monitor is Going Enterprise

---

Chapters

• 00:00:00 – Introduction
• 00:00:38 – Full Dashboard Overview
• 00:02:18 – Challenges with the Full Dashboard
• 00:04:00 – New Direction for the Tool
• 00:05:34 – Free and Extension-Based Solution
• 00:06:10 – Collection Service Details
• 00:07:33 – Light Viewer Overview
• 00:09:08 – Comparison with Full Dashboard
• 00:10:01 – 2022 VM Setup
• 00:11:30 – System Events and Performance Monitors
• 00:12:35 – Next Release Details

Full Transcript

Erik Darling here with Darling Data and in this video I’m going to talk about where the free SQL Server monitoring tool is headed in the near future and go over kind of what I’ve been working on, why I haven’t done a release in a couple weeks now. So when I first started working on this, my original goal was to make something very easy for people to set up and run depending on their preference or depending on certain requirements. There was what I call the full dashboard that created a database on your SQL Server, logged a bunch of things there, and you could query it, you could back it up, you could send it to someone, you could do whatever, just about whatever you wanted with it.

But there were some problems with that setup. One was that a lot of people thought that that would be the one database that everything got logged to that they were monitoring. They didn’t realize it was one database per server and that database had a tendency to get fairly big.

So I had to take some additional correct… When I first made the whole thing, you know, I made sure all the indexes were compressed and took various steps to try to keep things neat and tidy. But, you know, certain…

Collection elements like query text and query plans and blocked process and deadlock report XML tended to bloat things out. So some additional corrective steps I took were to use the compress and decompress functions on those things. And that cut down on the size quite a bit.

But the… And I think I haven’t gotten really any complaints about that stuff in a while. So hopefully that solved the problem.

But… The additional sort of friction for me was having to maintain two different code paths. If there was a bug in one, there might be a bug in two.

And getting my various clod army to remember that there are two and fixes need to go to both and not defer or downscope things randomly was a challenge. So that wasn’t fun. So my first idea was I could make a lot of the stuff…

Between the two monitoring tools into sort of shared libraries. And that way fixes would only need to go to one place. That didn’t quite go as I planned.

So… And I still had this sort of additional friction point of, you know, light being very, very popular. But, of course, light is a user application.

And if you close your laptop or shut down a VM that you have it running on… Or, you know, you close the dashboard, it stopped collecting. That was what full tried to sort of get rid of.

But full had its own problems that I’ve already talked about. Full was just agent jobs running, constantly collecting stuff. As long as your SQL Server was up, data was flowing. So that was…

So, like, neither one really solved the full picture. So what I’m doing now is I’m essentially deprecating the full dashboard. I am keeping the sort of…

Portable light version of that. It’s kind of like when you download Crystal Disk Mark. You have the full installer or just the zip that you can crack open and run. And choose your favorite anime girl theme. That’s the best.

So it’s sort of like that. Minus anime girls. Unless… If anyone wants to donate or, like, add some themes in to include anime girls, I’m totally fine with that. If you’re into that sort of thing, skin it up.

But, you know, it’s not my thing. No pillows with faces on them for Erik Darling. But…

So the direction that I went is… One, I wanted something that would still be free. Or at least as free as possible. And so I chose Postgres with the Timescale database plug-in.

Or… What do they call them? Extension in there. The reason for the Timescale thing is it offers incredible compression.

Like… Postgres on its own does compression pretty well. And they have this toast thing that kicks in for string columns of a certain size. And in Postgres 18 you get this crazy LZ4, I think, compression on stuff.

So, like, Query Text and Query Plan XML and the Deadlock and Block Process Report XML was already doing a pretty good job of staying nice and small and tidy. But we have the additional sort of Timescale thing kicking in and keeping things even smaller. Which is wonderful.

So Postgres is the chosen backend. That means you don’t have to pay for another SQL or worry about having to pay for another SQL Server. I know a lot of y’all out there really like putting your monitoring tools on Developer Edition. I’m not the licensing police.

But I’m just saying… Might be a little dodgy. Like, in terms-wise. But… You know… That’s…

Between… That’s between you and Microsoft. I got nothing to say about that. I am just a lowly consultant out in the world trying to make a difference. So, yeah. So it… The Postgres part is free.

You will pay the… Potentially pay the cost. You can bring your own Postgres, too, if you want. So if you already have a Postgres server running somewhere that you’re okay with having a monitoring tool database in, you can bring your own. Otherwise, you would just need a new VM or something that has the Postgres instance on it.

And what this thing… What this uses is a headless Windows service. Headless meaning it is not tied to a user.

It is part… It is running on Windows regardless of… Well, I mean, unless you shut the VM down completely. Right? If it goes to sleep or you log out or something, it’s fine.

But… If you shut the VM down, you… I can’t… I can’t help you with that. So it’s running constantly the way that the agent jobs in Fullwood to collect data and put it into Postgres. And it’s sort of…

And it completely detached the collection service. The collection service from the viewer. So if you have multiple users… This is another friction point was getting this so that multiple users could all ping in and see the same set of stuff all at once.

You can do that. This also allowed for some neat security stuff where there is like an owner account that can do anything. There is an admin account that is allowed to change schedules and collection stuff and alerts and whatnot.

And then there’s just a reader only. So if you have folks who shouldn’t be… Who you don’t trust to tinker with those things, they can… They have a read only path to see the monitoring data without being able to mess with anything.

So all good there. And now we have, behold, a viewer with some improvements, I think. And if you’re asking how this solves the double bug thing for me, it doesn’t completely but it does make it easier.

Because much more of the viewer code… Viewer code path stuff is shared between light and this thing than with the full dashboard. So that’s good there.

Anyway. What was I saying? Yes. Good. So now we have this. And I’ve made some visual improvements and some performance improvements to things along the way. So you start off with what you would normally see when you open up light pretty much.

Again, some improvements. We’ve got some new stuff up here that show you the number of servers. How many are healthy and all that stuff. And then you have the normal sort of NOC style dashboard in here.

I believe HammerDB is… No, I think maybe… No, HammerDB probably finished on 2025. That’s why things are all green and happy over here. But going into the monitoring data itself, we can see…

Actually, let me set this to the last like four hours so that things are a little bit more zoomed in to when we had HammerDB running and doing stuff. So this is the sort of normal stuff that you see. We have our overview here.

We have our weight stats here that includes top weights and, you know, like the top weights that you have in here along with some of my favorite weights to show people. There are some neat additions when you like click on stuff and look at things in here. But you can just as always, if you want to, you know, see queries causing a problem, you right click, you get to those queries.

And under the queries tab, we have all the… Again, just same user experience as light. Just with a different back end that is a constantly running collector to get stuff from.

So all the stuff that you would want to see in here. The UI is a lot snappier too. I think clicking around through here, sometimes there were some long pauses on things I was always mad about.

But now everything seems pretty snappy. There are some new collection metrics in this one as well that, you know, give you a little bit more information. You know, there was some stuff in full that I liked.

That I wanted to get further into. So I’ve got all this stuff in here. And there’s no memory pressure events on SQL Server 2025. But over on 2022, if we look, we can see some memory pressure events if we go back to the last 24 hours.

You can see where, you know, SQL Server 2022. So SQL Server 2022 is my old prod VM that has been downgraded to like 2 gigs of memory and 4 cores or something. This thing gets beat up a little bit easier.

But 2022. 2025 is where I do like all my new development work and stuff. Now it seems pretty safe and worked out. So we’ve got all this stuff in here.

All the same stuff that you would expect. One big thing that I corrected on the advice of the lovely and talented Kendra Little was TempDB has been unpropercased. And it is now in its proper state.

Right? All lowercase. Good. Right? That’s nice there. But everything that you would want to see around blocking and everything. Right?

That stuff. Current weights. Look at all those wild spikes. Look at our blocking stats. Look at our block process reports. And our deadlocks. And our perfmon. Right?

And perfmon. Remember perfmon has all the different collector packs in here. So depending. So like you don’t have to remember all the stuff that you want to see. All the counters that go into certain perfmon things. And other stuff that was brought over from full into this that wasn’t in light.

We have stuff like session stats so you can see what things were running. Like sleeping background total. All that good stuff.

We have our usual agent job things going on. Our usual configuration and configuration changes stuff. One thing that I did change.

So daily summary used to be just a one line about today. Like this isn’t all lit up obviously because I haven’t. It’s kind of new. Right?

So it’s like new data. But one thing I changed in here is I made this a calendar view where you know like you can see the good days and the bad days. And then you can like sort of click and see what was going on with the good days and bad days down here. And you can you know it’s like oh you had a lot of deadlocks and blocking and crappy queries.

So you can go and look and stuff in there. So this is an improvement I think. System events.

There’s not a lot in here because this is all from the system health extended event. And quite frankly once again. The oh crap section. If you have a lot of stuff in here. You might want to hire a young handsome consultant with reasonable rates like yours truly to come help you with your server.

We’ve got some latch and spin lock stuff in here that got promoted in from the full dashboard. Because some people despite best efforts still care about this stuff. And of course the collection health stuff where you know I get to tell you how well my performance monitor collector is doing.

So this is. This will be in the next release. Available I want to say in the next few days or so.

Most of the work is done. There is just a little bit of polish that needs to be completed. And once that is all done.

Sorry. So mid week or so. Well actually you’ll be seeing this on Thursday. So it might have even been released by the time you see this. We’ll see how that.

We’ll see how that plays out. Anyway. This is where things are. This is where things are headed. Much closer to sort of an enterprise monitoring tool than the previous versions. This.

If I had to put a high number on it could probably support about 500 servers. If it needed to. If you have 500 servers. God bless.

And again this is totally free. There is no cost to you. There is no per server or anything. If you want to donate money to this project you can. If you want to. If you need a support contract that stuff is available.

But otherwise it’s just totally free monitoring. You can get it at code.erikdarling.com. That will bring you to my GitHub repo. And it’s just under the performance monitor section.

So anyway. That’s where things are at. Thank you for watching. I hope you enjoyed yourselves. I hope you’ll use the monitoring tool in its full enterprise glory. And if you have any questions, comments, concerns, problems.

That’s what GitHub is for. Otherwise. Thank you for watching. Goodbye.

Going Further

---

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.

The post Performance Monitor is Going Enterprise appeared first on Darling Data.