AutoExplore Blog

Hunting a Windows ARM crash through Rust, C, and build-system configurations

2026-04-24T00:00:00Z

Hunting a Windows ARM crash through Rust, C, and build-system configurations

A routine allocator update turned into one of the most interesting debugging sessions I have had in a while.

Working on my Rust projects GitComet and AutoExplore, we use mimalloc for memory allocation. It has been a great fit for both projects and helped reduce memory usage noticeably, so updating it felt like routine maintenance.

Upgrading to mimalloc 3.3 suddenly broke the Windows ARM64 CI pipeline. Linux passed. macOS passed. x86_64 Windows passed. Only aarch64-pc-windows-msvc failed, and it failed hard:

(exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

No stack trace. No helpful panic. No obvious clue.

That was the moment this stopped being a dependency update and turned into a bug hunt.

The kind of failure that gives you nothing

The only change in the pull request was the mimalloc upgrade, and the previous version did not produce the error.

That narrowed the problem down enough that I opened an issue in mimalloc, because the regression looked real. The maintainer suggested trying -DMI_WIN_INIT_USE_TLS_DLLMAIN=1, which was a good lead, but I hit another problem immediately: I was using mimalloc through the Rust crate mimalloc_rust, and I did not yet understand how to pass that kind of flag through the Rust build.

That part turned out to be unexpectedly educational.

I had always treated mimalloc_rust like a normal Rust dependency, but under the hood it compiles a C codebase as part of the crate build. Looking through the sources, I found the cc crate, which is the standard bridge Rust uses to compile C, C++, assembly, and even CUDA during build.rs.

fn main() {
    cc::Build::new()
        .file("native/hello.c")
        .compile("hello");
}

That is the basic shape: a Rust crate can look ordinary from Cargo's point of view while still compiling native code during the build.

Simple example of building C sources through Rust build system using CC

First reaction: turn on more debugging

My first instinct was simple: compile mimalloc with more diagnostics and get a better failure.

I found that mimalloc exposes flags like MI_DEBUG and MI_SHOW_ERRORS through Cargo environment variables, so I turned those on and reran the failing job.

Same crash. Same exit code. Still no stack trace.

Normally that is where a bug like this stalls for a while.

Using CI as a remote debugger

Since I could not reproduce the problem locally, I tried to get the failing GitHub Actions runner to capture a dump at the moment of the crash.

I used ProcDump from a PowerShell script in CI to watch the test binary, catch the unhandled exception, and upload the resulting dump as an artifact. GPT-5.4 helped speed up that part by generating the right command-line plumbing for ProcDump and the artifact upload steps.

Linux, macOS, and x86_64 Windows were green. Only the Windows ARM64 lane failed.

After a few iterations, I got the dump.

And finally, the failure had a shape:

This dump file has an exception of interest stored in it.
(290c.71c): Access violation - code c0000005
gitcomet_5e0245ab8a6fea4a!_InterlockedCompareExchange64+0xc
Attempt to write to address 00007ff743eb4b88

STACK_TEXT:
gitcomet_5e0245ab8a6fea4a!_InterlockedCompareExchange64+0xc
gitcomet_5e0245ab8a6fea4a!_mi_malloc_generic+0x44
gitcomet_5e0245ab8a6fea4a!_mi_theap_malloc_zero+0xd8
gitcomet_5e0245ab8a6fea4a!std::sys::pal::windows::to_u16s::inner+0x60

The most important clue was that the crash happened inside _InterlockedCompareExchange64, with an access violation on Windows ARM64. In other words, something that looked like a read path was going through an atomic compare-and-exchange operation and touching memory it was not allowed to modify.

That was the first moment the bug became exciting instead of frustrating.

The bug was a load that was not really a load

Once I had the dump, I started digging into mimalloc's atomic code. I am not a daily C or C++ engineer, so this meant slowing down and understanding what the code was actually trying to do.

In one code path, mimalloc was effectively using compare-and-exchange as if it were a load. That sounds harmless at first, because the code was comparing x and writing back the same x. But on ARM64, that is still not a plain read. It is a read-modify-write atomic operation.

That difference mattered because the pointer being accessed could point into sentinel objects like mi_theap_empty or mi_page_empty, which live in read-only memory.

A code path wanted an ordered load.
Instead of performing a true load, it used compare-and-exchange.
On Windows ARM64, that became a write-capable atomic instruction.
The target happened to be read-only sentinel storage.
Windows raised STATUS_ACCESS_VIOLATION.

That is the kind of bug that can stay invisible for a long time because it depends on three things lining up at once: a specific architecture, a specific compiler lowering, and a specific object layout.

There was also a const-correctness problem in the pointer load macros. The old macros cast away const, which made it easier for the type system to accept a path that could mutate memory even when the underlying storage should have been treated as read-only. Fixing that did not just make the code prettier. It made the contract clearer: loads should accept read-only storage, and load helpers should stay loads.

Part of the fix was tightening the pointer load macros so they preserve const instead of silently casting it away.

The functional fix was even more important. The compare-and-exchange loop was removed from the load path and replaced with real ordered load operations on ARM, using the correct intrinsics for acquire semantics.

The old code was "reading by doing CAS," while the fixed code was "reading by doing an actual ordered load."

Once you see it that way, the crash makes perfect sense.

The real functional change was replacing the compare-and-exchange loop with architecture-appropriate ordered loads on ARM.

The real surprise was not just the bug, but how we built it

At that point I understood why the access violation happened, but why had this not been caught sooner?

The answer led back to the build system.

Upstream mimalloc was not being compiled the same way as the Rust wrapper in my project. On the MSVC and Windows ARM family of targets, upstream behavior was compiling the code as C++, while the Rust wrapper still compiled static.c as C through build.rs. In the C++ version, that particular atomic file was not included in the output, and the C++ path relied on its own atomics implementation.

So this was not just a low-level allocator bug. It was a mixture of:

Rust and C
Crate build scripts and upstream build logic
Architecture-specific atomics and compiler behavior on Windows ARM64

That is exactly why it was so difficult to spot from the outside.

The workaround on our side was to compile mimalloc more like upstream does for Windows ARM and MSVC-family targets, including using the C++ compiler path there. I also raised the upstream issue and put together a PR on our side to address the Rust build differences.

I enjoyed this bug far more than I expected to.

It started with a useless exit code and ended up teaching me several things at once:

how Rust crates can compile and ship C code under the hood
how to capture crash dumps from CI even without direct access to the target device
how small type-system lies around const can enable real platform bugs
how one architecture can expose assumptions that seem harmless elsewhere
how build-system differences can be just as important as source-code differences

That is why this felt worth writing up. It was not just "I fixed a crash." It was a reminder that some of the best debugging sessions force you to understand the layers below the one you normally work in.

If you enjoy this kind of investigation, GitComet is the tool we are building for exactly this style of work: engineers chasing real regressions through code diffs, dependency updates, and cross-platform behavior.

GitComet Release

2026-03-12T00:00:00Z

GitComet Release

At AutoExplore, we work with large repositories and large file diffs every day. We tried multiple graphical Git clients, but we could not find one that stayed fast and usable for the workflows we needed.

Because of that, we built GitComet and started using it internally to manage our own Git workflows.

Today, we are also releasing GitComet publicly as open source, so anyone can use it. GitComet is free for both individuals and organizations.

What GitComet is

GitComet is a fast, local-first Git GUI written in Rust. It is designed for teams that want familiar Git workflows with better responsiveness in large codebases.

What you can do with GitComet

Browse repository history and inspect changes in a desktop UI
Stage, unstage, and commit with familiar Git workflows
Work with branches and worktrees
Use focused diff and merge tooling for day-to-day code review and conflict resolution
Run it as a standalone app or integrate it into git difftool and git mergetool

GitComet is available for Linux, macOS, and Windows.

Easy difftool and mergetool setup

If you want to use GitComet directly from Git, you can configure it with:

gitcomet-app setup

And remove the integration later with:

gitcomet-app uninstall

Open source and free

GitComet is open source under AGPL-3.0 and available for free use by individuals and organizations.

To try it now:

Download releases from GitHub Releases
Explore the source code at Auto-Explore/GitComet
Learn more at gitcomet.dev

Autonomous Testing Agent Benchmark in works

2026-02-17T00:00:00Z

Autonomous Testing Agent Benchmark in works

At AutoExplore, we’re building a benchmark to evaluate and improve agentic exploratory testing capabilities.

Our goal is simple: create a fair, transparent way to measure how well autonomous agents explore, detect issues, and learn from software systems.

We are looking for input from testing professionals and developers. Measuring the wrong things can distort behavior. Measuring the right things can unlock real progress.

What do we mean by “exploratory testing” for agents?

One of the first questions we got from the community was: how are we defining exploratory testing here?

In human testing, exploratory testing is often described as simultaneous test design and execution, guided by learning and discovery. Some people will question whether agents can truly do that today. It may be that what agents do right now is something new that sits between mechanical script execution and human-led discovery. (Ministry of Testing: What should we measure in exploratory testing?)

Our working definition for this benchmark is intentionally simple:

We do not tell the agent what to test (no test cases, no scripted steps, no predefined assertions).
The agent decides what to explore, what to try next, and what to report as issues.
We evaluate the results (coverage, findings, report quality, efficiency) using transparent scoring.

If you think this definition is wrong (or too broad), we want to hear that too. The definition drives the incentives.

What we are currently planning to measure

1) Exploration and coverage

Exploratory testing is about navigating unknown territory without being told exactly what to do. We want to measure how broadly and deeply an agent explores, without prescribing a strategy.

We are currently tracking metrics like:

Number of discovered views, pages, and URLs
Coverage of interactive elements
Links tested (count and proportion)
Buttons tested (count and proportion)
Inputs tested (count and proportion)
Total number of operations performed
Data entry variations attempted
Order-of-operation permutations (how many distinct sequences were exercised)

These counts are not the end goal. They are instrumentation signals that help us understand whether the agent touched the product at all, and whether the tool is stable. On their own, they do not capture the core value of exploratory testing: discovery, learning, and risk reduction.

What we want to avoid is a benchmark that rewards mindless clicking. Coverage should reflect meaningful exploration, not just activity.

2) Defect detection quality

Finding bugs is not enough. Reporting noise is costly, and missing critical issues is worse.

We are thinking in confusion-matrix terms:

	Reported as issue	Not reported
Real defect	True positive	False negative
Not a defect	False positive	True negative

From this we can measure:

Precision (how many reported issues are real)
Recall (how many real defects get reported)
Signal-to-noise ratio (useful findings vs noise)

The tricky part is definitions: what counts as “the same issue”, what severity bucket it belongs in, and how to score partial reports.

In practice, our approach is: the agent produces a human-readable report, and then a judge (human, another agent, or both) classifies the outcome so we can compute precision/recall.

An example of a strong defect report format is:

Expected: Clicking “Create a free account” should open a registration flow with the required fields.
Actual: The UI stays on the login form and the registration fields never appear.
Reproduction steps: Open the page, click the “Create a free account” button, observe the missing registration flow.

3) Efficiency

Exploration is also about discovering value quickly.

We want to measure:

Total test time
Time to first defect
Time to first critical defect

What else should we measure?

This is where we need the community. If you have opinions (or hard-won lessons), we’d love to hear them.

Here are some candidate areas we are considering, but we do not want to bake in the wrong incentives:

Example: a charter-based perspective

Exploratory testers often work with session charters, for example:

Mobile connectivity: Explore the app with a poor network connection to discover whether it still works as expected or provides helpful error messages.

If we wanted metrics for that single charter, we might measure things like:

Behavior under network profiles (slow, loss, intermittent offline)
Whether critical flows still complete (or fail safely)
Error message quality (clear, actionable, not misleading)
Recovery (retry works, state is preserved, no duplicate submissions)
Evidence quality (screenshots, network traces, timings, logs)

Report usefulness

Reproducibility (are the steps sufficient and deterministic?)
Deduplication (does the agent file the same issue repeatedly?)
Quality of evidence (screenshots, logs, timings, network traces, console output)
Severity and priority classification accuracy
Minimization (can it reduce to the smallest set of steps that still reproduces?)

Depth and state coverage

Unique UI states reached (not just pages or URLs)
Multi-step flows covered (for example onboarding, checkout, role-based paths)
Data state variation (different users, permissions, seeded datasets)
Negative-path exploration (invalid inputs, boundary values, empty states)

Robustness and autonomy

Recovery from dead ends (modals, error pages, expired sessions)
Resilience to flaky UI behavior (timing, spinners, animations)
Ability to continue exploring after encountering failures
Avoidance of destructive actions in shared test environments

Learning across runs

Reduced repetition (does it avoid re-testing the same things?)
Novelty rate (how much new surface is discovered per unit time)
Regression detection (does it re-validate known risky areas after changes?)
Knowledge transfer (can it reuse what it learned on one app to bootstrap another?)

Cost

Compute cost per hour of testing
Cost per unique defect (or per high-severity defect)
Browser and API resource usage

If you have a strong take on any of these (or you think we should ignore some entirely), email me at sampo.kivisto@autoexplore.ai.

We are also looking for benchmark applications

We are searching for test applications with a known, documented list of issues.

Ideally:

Publicly available
Designed for testing practice
With known defect catalogs (so we can score false positives and false negatives)

If you know applications built for this purpose, we’d love to evaluate them for inclusion in the benchmark. We will credit you and the original author.

When you suggest an app, it helps if you can include:

Link to repo and license
How to run it locally (or hosted URL)
Where the defect list lives (docs, issue tracker, challenge list)
Any notes about which issues are in scope (UI, API, accessibility, security, performance)

AutoExplore is live!

2026-01-20T00:00:00Z

AutoExplore is live

Today we are launching AutoExplore.

AutoExplore delivers always on, autonomous testing that navigates your app like a real user. It clicks links, fills forms, and explores flows continuously, without test scripts. The goal is simple: help teams catch issues earlier, reduce regressions, and ship with more confidence.

What you can do with AutoExplore on day one

Always on exploration

Point AutoExplore at a Target Software Environment, provide credentials, and let the agent run. AutoExplore explores your UI in a real browser, interacting with the same elements your users interact with.

Actionable issue reporting

Autonomous testing produces a lot of signal. AutoExplore turns that signal into reports that are easy to understand and easy to reproduce.

In the reports view, findings are categorized into areas like Errors, Audit, Performance, Deprecations, Accessibility, Security, and more. Each finding includes a timeline that shows what happened before, during, and after the issue, with screenshots and technical details. Related: AutoExplore issue reporting.

Coverage you can see

Understanding what an autonomous agent touched is just as important as the bugs it finds. AutoExplore provides a visual coverage view that highlights which UI elements were interacted with and where. Related: Measuring AI Agent Coverage.

Built in accessibility testing

AutoExplore continuously scans for accessibility issues while it explores your app, helping you catch problems and edge cases without having to put the application into specific states manually. Related: Accessibility Testing.

Integrated security scanning

AutoExplore includes a safe, non destructive security scanner that analyzes your application as the agent navigates, helping surface misconfigurations like missing headers and insecure cookies with reproducible steps. Related: AutoExplore Security Scanning.

Scale across environments and teams

Whether you want parallel testing across staging and production, or you want to run multiple agents against the same environment with different users, AutoExplore supports multiple Target Software Environments and multiple Agents. Related: Multiple Environments Multiple Agents.

If you want to reduce cost while still testing multiple smaller apps, you can share one agent across targets by scheduling it to rotate between environments. Related: AutoExplore Agent Scheduler.

Who AutoExplore is for

AutoExplore is built for teams that ship and iterate fast, and want an extra layer of validation beyond unit tests, scripted end to end tests, and manual QA.

It is a good fit for:

SaaS products and customer portals that change frequently
Internal tools that are business critical but hard to cover with scripts
Teams that want continuous regression coverage, not just pre release checks
Organizations that need security and accessibility visibility as part of QA

How to get started

Start a 7 day trial at app.autoexplore.ai
Create a Target Software Environment for your staging or production app
Add test credentials and start the agent
Review the first findings, then tune your setup (environments, users, and schedules)

If you want a guided walkthrough, book a live demo and we will help you set up AutoExplore for your application.

At AutoExplore, we are committed to helping R&D teams implement autonomous testing as part of their development processes. Ready to see what issues AutoExplore finds from your application? Contact us for a demo to learn more.

AutoExplore Agent Scheduler

2026-01-07T00:00:00Z

AutoExplore Agent Scheduler

Many teams don’t have just one product to test. They have a customer portal, an internal admin tool, a public website, and maybe a couple of smaller apps. If you provision a dedicated autonomous testing agent for each application, your testing cost scales with the number of apps.

At the same time, a single AutoExplore Agent can only test one application (Target Software Environment) at a time.

The AutoExplore Agent Scheduler solves this by letting you time‑share one agent across multiple applications: the agent rotates between your selected target environments on a schedule, so each application gets its own testing window.

Think of the scheduler as a rotation plan:

You define an ordered list of Target Software Environments (each can point to a different application or environment).
You pick when the agent should move to the next target.
AutoExplore automatically switches the agent to the next target when the schedule triggers.

To enable rotation, the scheduler must have at least two different target environments configured.

Scheduling modes

The scheduler supports multiple ways to define the rotation cadence:

Interval: rotate every N minutes (minimum 60 minutes between rotations)
Time of day: rotate once per day at a specific time
Weekly: rotate on a chosen weekday + time, optionally every N weeks

In the Control Panel, scheduler times are interpreted and shown as UTC-0.

How to set it up

In the AutoExplore Control Panel:

Open your agent’s settings and go to Agent Scheduler (currently marked as Beta).
Add the Target Software Environments you want the agent to rotate between and arrange them in the desired order.
Pick the schedule type (Interval / Time of day / Weekly) and configure the time(s).
Use the preview to sanity-check the upcoming rotation plan.
Toggle the scheduler to Enabled to start automatic rotation.

Preview before you enable

Before you turn the scheduler on, you can preview upcoming rotations. This helps you answer questions like:

“Which app will the agent be testing tomorrow at 09:00?”
“How long is each testing window with my current settings?”
“Does the rotation order match our priorities?”

The preview is especially useful when you’re coordinating testing windows across multiple teams that share the same agent.

Per‑target “move‑out” deadlines (optional)

Some environments have hard constraints. For example, you might want the agent to leave production before business hours, or leave staging before a deployment window.

For each target environment in the rotation, you can optionally set a move‑out before time (and an optional buffer in minutes). When configured, AutoExplore will not schedule the next rotation later than that deadline for that target.

Practical tips

Prefer longer windows: rotating too often can reduce the time the agent spends exploring deeper flows.
Use UTC intentionally: align the rotation plan with your teams’ working hours and release windows.
Monitor upcoming transitions from the agent pool: you can see when the next rotation is scheduled and which target is next.

When to use the Agent Scheduler

The scheduler is a good fit when:

You have multiple smaller applications that one agent can cover within a reasonable timeframe
Some of your target environments aren’t running 24/7 and you want the scheduler to align testing windows to reduce cost
You want to standardize testing windows (e.g., nightly, mornings, weekends)

If you need parallel testing (multiple apps at the same time), you’ll still want multiple agents. The scheduler focuses on sequential sharing. Related: Multiple Environments Multiple Agents.

AutoExplore Security Scanning

2025-10-20T00:00:00Z

AutoExplore Security Scanning

Information security has always been a cat and mouse play. As the technology evolves, it also opens doors to new attack methods. Building secure software today requires more than end-to-end encryption. It needs continuous vigilance: patching known vulnerabilities, mitigating emerging exploits, and validating that web applications are configured securely.

A different Way to Scan

AutoExplore’s latest update introduces an integrated security scanner that enhances web application testing by combining security analysis with intelligent exploration. All network traffic between the AutoExplore web browser and the target application is proxied through ZAP Proxy, an open-source security tool.

As the AutoExplore agent navigates the application like a real user, it discovers and scans parts of the user interface that traditional crawlers might miss. This approach enables deeper and more comprehensive security coverage.

Detecting Security Misconfigurations

The scanner evaluates critical security response headers and configurations, such as:

Content Security Policy (CSP) ensuring protections against cross-site scripting (XSS).
Server information headers verifying that software version details aren’t exposed.
Cross-Origin and Site Isolation policies checking for proper mitigation against Spectre-like vulnerabilities.

For example, missing or incorrect site isolation headers can make an application more vulnerable to data leaks between browser processes (e.g. Spectre attacks). These can often be mitigated by appending specific HTTP response headers or annotating HTML elements with attributes that guide browser behavior. Learn more on MDN: Cross-Origin-Embedder-Policy

The scanner also highlights authentication and session management weaknesses, such as insecure cookies, missing SameSite flags, or session fixation risks.

Reproducible and Actionable Findings

Like all other issues in AutoExplore, every security observation includes a timeline view that captures the exact steps leading to the finding. This allows developers and security teams to easily reproduce and validate vulnerabilities.

Each issue is automatically assigned a risk level, helping teams prioritize effectively.

Application defense is only as strong as its weakest link

Unlike traditional crawlers, AutoExplore renders the web application in a real browser and uses machine learning models to detect interactive elements and dynamic states. This ensures comprehensive coverage — including hidden menus, modal dialogs, or authenticated pages that typical scanners might miss.

Secure by Design

Importantly, AutoExplore’s security scanner performs non-destructive analysis — it inspects responses but does not attempt to exploit or attack the target software. This makes it safe to use across different hosting environments.

Next, our focus shifts to improving reporting and navigation to make exploring findings even more intuitive.

At AutoExplore, we are committed to helping R&D teams implement autonomous testing as part of their development processes. Ready to transform your process? Contact us for a demo to learn more.

Accessibility Testing

2025-10-07T00:00:00Z

The European Accessibility Act 2025

On June 28, 2025, the European Accessibility Directive EU Directive 2019/882 came into effect. The European accessibility act requires minimum accessibility standards for a wide range of products and services. It is aimed to ensure that people with disabilities can use products and services.

While the legislation is aimed at people with disabilities, it also impacts software programs and tools. In the AI era, where task automation is becoming more common, it is important to ensure that your web application is accessible.

Agents and Tools

Screen readers and basic web crawlers which are integrated into LLM often rely on the accessibility tree provided by the web browser. To make your application accessible, you need to make sure that the accessibility tree is correct. W3C provides an Accessibility Standard to help in building accessible websites and web applications.

Accessibility tree is used to tell information about the page. Incorrect accessibility tree can cause the following issues:

Some part of the page is not "seen" by the assistive tool or agent. This can cause confusion or lose sales
Test automation tools may not be able to interact with the page
Some users may not be able to use the page and legal issues may arise
Search engines may have less visibility due to missing information
Bad user experience due to unclear or confusing UI, weird tab order, etc.

Accessibility Tree

You can access the accessibility tree in the browser developer tools. In FireFox you can open the accessibility tree by selecting Accessibility tab from the developer tools. In Chromium-based browsers, you can open the accessibility panel from the "Elements" panel and changing the view by clicking the "Accessibility" button.

The browser accessibility tree view gives a quick look into the page and how it is structured and what information is available. You can also use FireFox accessibility tree for analyzing tab-order quickly.

There are also external tools that help you how to improve the accessibility of your web application during the development process.

You can integrate these tools into your browser for manual checks or playwright / cypress tests for tracking regressions.

One of the challenges with accessibility testing for modern web applications is that you always have to have the application in a specific state when scanning for accessibility issues. For example, to detect if your dropdown is accessible, you need to get the application into a state where the dropdown is visible, scan the application and then open the dropdown and scan again, then repeat this process for all the elements and pages.

In a recent AutoExplore update we added accessibility testing capabilities to our testing agent. This means when the agent browses the application, it is also continuously scanning for issues and reporting findings autonomously. It helps find edge cases that could be missed easily.

At AutoExplore, we are committed to helping R&D teams implement autonomous testing as part of their development processes. Ready to transform your process? Contact us for a demo to learn more.

null, undefined, NaN, [object Object]

2025-09-15T00:00:00Z

null, undefined, NaN, [object Object]

One common mistake in Web development is to use the value of a variable or property that is not in the expected state. JavaScript has two bottom values: null and undefined. Due to the widespread use of JavaScript, it is common to see these values rendered in the UI. Most of the time, these values are not intended for the end user and can be confusing. The AutoExplore agent is now able to detect these values and highlight them in the reports.

Root cause

The null value is used to represent the absence of a value. The undefined value is used to represent the value that is not yet defined.

Technically, these values end up in the UI due to a string interpolation where the read value is not defined. Before quickly rushing into a fix, it is crucial to understand the root cause of the issue. Rendering price as 0 is different from not having a price set.

NaN is a special value that represents a mathematical operation that cannot be performed. These values can end up in the UI due to incorrect calculations or invalid input values. When price is calculated and the formula contains an invalid value, the result is NaN.

[object Object] is a special value that represents an object. This value can end up in the UI when the developer expects a value or property to be a string, but the value is an object. It is common to see these values in the UI after library or API updates, something that used to be a string has been changed to an object.

Detection

The AutoExplore agent is now able to detect these values and highlight them in the reports. OnScreenError is the new error type used to categorize this type of issues. OnScreenError also contains other error-looking texts from the UI other than just null, undefined, NaN and [object Object]. You can use the timeline view to see the exact steps the agent took for reproducing the issue. The final step highlights the value where it was detected.

At AutoExplore, we are committed to helping R&D teams implement autonomous testing as part of their development processes. Would you like to see what issues AutoExplore finds from your application? Contact us for a demo to learn more.

Multiple Environments Multiple Agents

2025-09-03T00:00:00Z

Multiple Environments Multiple Agents

Since AutoExplore's recent update, it is possible to run multiple agents in parallel against multiple environments. This allows testing multiple versions of the application under test, for example, production and staging environments. It can also be used to speed up the testing process by running multiple agents against the same environment.

Multiple Target Software Environments

You can now create multiple Target Software Environments to better fit AutoExplore as part of your development workflow.

You can freely move the Agent between different Target Software Environments.

Having multiple target software environments allows different testing strategies, for example:

Test different hosting environments, (staging and production)
Test different versions of the application, (v1 and v2)
Test different configurations of the application, for example: with and without certain features enabled
Test different branches of the application, (main and develop)

You can also use multiple Target Software Environments to test different applications, e.g. Financial App and Shopping App. This is useful if you have multiple applications that you want to test with the same AutoExplore instance, however one AutoExplore Agent is able to test one Target Software Environment at a time

Multiple Agents

To better support the extended Target Software Environments feature, we have also added support for multiple Agents. You can now purchase additional Agents in AutoExplore organization settings to enable multiple Agents in your organization. Each Agent can be assigned separately to selected Target Software Environment. Multiple Agents opens additional testing strategies:

Parallel testing of different Target Software Environments, (staging and production)
Simultaneous testing of same Target Software Environment with different user credentials, for example: admin and regular user
Testing integration between different applications, (Financial App and Shopping App)
Speed up testing by running multiple Agents against the same Target Software Environment

AutoExplore issue reporting

2025-05-06T00:00:00Z

AutoExplore issue reporting

Autonomous testing without specified test cases creates a unique challenge for issue reporting. How to present the information about the found issues in a way that it is easy to understand and reproduce without overloading the user with too much information?

Report categories

During test agent execution, the agent tests and analyzes many different aspects of the service under test in parallel. These analyzed aspects include HTML markup, network traffic, rendered user interface, application logs, and many more. As the agent executes, without breaks or pauses, it quickly generates a lot of information about the application.

The main reports view tries to help navigate this issue list by categorizing similar types of issues into groups.

These categories are

Errors Uncaught Javascript exceptions, failed http requests, error logs from browser console.
Audit Browser audit results, form validation issues, client side validation etc.
Performance Performance related audits, network traffic performance, page load times and slow Javascript code.
Deprecations Deprecated API usage, deprecated HTML elements, deprecated CSS properties.
Accessibility Accessibility issues, missing aria attributes, missing alt attributes, low text contrast etc.
Security Security issues, missing security headers, insecure http requests, insecure cookies.
External Issues detected outside the configured application domain.
Reasoning LLM reasoning results from the service under test
Other Issues that do not fit into any of the above categories, for example: Agent getting stuck on a specific view.

Each category can then be opened in a separate view that shows a list of issues that belong to that category. The list of issues is again grouped by the similarity of the issue. This allows counting how many times a similar issue has occurred and when it was first and last seen. Finally, selecting a group opens a detailed view of the issue.

Detailed view

The detailed view shows the lowest level of details about the reported issue. It allows navigating through different variations of the same issue. It is useful to better understand the scope of the issue. If, for example, the same error has occurred on multiple pages, it can be related to a certain widget or a user flow.

Below the occurrence navigation menu, there is a timeline view that shows what the agent did during the selected occurrence and what happened on the application before and after the issue occurred. Timeline view allows navigating the agent steps using screenshots from the application, as well as understanding network race conditions by seeing when the network request started and when it finished. Certain issues only occur when network requests finish in an unexpected order.

Following the agent steps in the timeline view can help to understand the issue better and reproduce it, the steps can be easily followed even without technical knowledge.

Finally, the detailed view shows the information about the issue itself. This information varies depending on the type of issue.

AutoExplore Blog

Hunting a Windows ARM crash through Rust, C, and build-system configurations

Hunting a Windows ARM crash through Rust, C, and build-system configurations

The kind of failure that gives you nothing

First reaction: turn on more debugging

Using CI as a remote debugger

The bug was a load that was not really a load

The real surprise was not just the bug, but how we built it

Why I wanted to share this

GitComet Release

GitComet Release

What GitComet is

What you can do with GitComet

Easy difftool and mergetool setup

Open source and free

Autonomous Testing Agent Benchmark in works

Autonomous Testing Agent Benchmark in works

What do we mean by “exploratory testing” for agents?

What we are currently planning to measure

1) Exploration and coverage

2) Defect detection quality

3) Efficiency

What else should we measure?

Example: a charter-based perspective

Report usefulness

Depth and state coverage

Robustness and autonomy

Learning across runs

Cost

We are also looking for benchmark applications

AutoExplore is live!

AutoExplore is live

What you can do with AutoExplore on day one

Always on exploration

Actionable issue reporting

Coverage you can see

Built in accessibility testing

Integrated security scanning

Scale across environments and teams

Who AutoExplore is for

How to get started

AutoExplore Agent Scheduler

AutoExplore Agent Scheduler

What “sharing one agent” means in practice

Scheduling modes

How to set it up

Preview before you enable

Per‑target “move‑out” deadlines (optional)

Practical tips

When to use the Agent Scheduler

AutoExplore Security Scanning

AutoExplore Security Scanning

A different Way to Scan

Detecting Security Misconfigurations

Reproducible and Actionable Findings

Application defense is only as strong as its weakest link

Secure by Design

Accessibility Testing

The European Accessibility Act 2025

Agents and Tools

Accessibility Tree

null, undefined, NaN, [object Object]

null, undefined, NaN, [object Object]

Root cause

Detection

Multiple Environments Multiple Agents

Multiple Environments Multiple Agents

Multiple Target Software Environments

Multiple Agents

AutoExplore issue reporting

AutoExplore issue reporting

Report categories

Detailed view