.add_systems DONT WORK

[KeiMuriKoe]

Bevy version

current main version - 0.15

What you did

I wanted to try out a new engine (Bevy) and started following the "Get Started" documentation. Things went off track when I tried to use app.add_systems It seemed like such a basic and straightforward function that should definitely work, so I feel like I must be missing something. But for some reason, it just doesn't work—the simplest example code doesn't run for me. Everything else I've tested so far works perfectly fine for me. Fot example connecting plugins. When installing rust and bevy, I strictly followed the provided instructions. Also example was working for me.

use bevy::prelude::*;

fn main() {
    let mut app = App::new();
    app.add_systems(Startup, hello_world);
    app.run();
}

fn hello_world() {
    println!("hello world");
}

Windows 11.

What went wrong

INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 6700 XT", vendor: 4098, device: 29663, device_type: DiscreteGpu, driver: "AMD proprietary driver", driver_info: "24.4.1 (AMD proprietary shader compiler)", backend: Vulkan }
error: process didn't exit successfully: target\debug\my_bevy_game.exe (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

Additional information

[viridia]

Interesting. Curious to know if adding the DefaultPlugins to app makes it work.

[PhantomMorrigan]

yeah you need DeafultPlugins or MinimalPlugins, otherwise you App won't have a runner, and thus can't run iirc.

I was wrong sorry.

[viridia]

If that's the case, then the example in the documentation is wrong.

[PhantomMorrigan]

Actually I retract what I said earlier, this should work. Also, It does actually work, at least on Linux.

Try checking if there is some antivirus software breaking things? I've at least seen that happen before.

[KeiMuriKoe]

Interesting. Curious to know if adding the DefaultPlugins to app makes it work.

if add DefaultPlugins it works, but not with add_systems

[KeiMuriKoe]

Actually I retract what I said earlier, this should work. Also, It does actually work, at least on Linux.

Try checking if there is some antivirus software breaking things? I've at least seen that happen before.

i dont have any)

I have completely removed the antivirus from my Windows system and I don’t use any third-party ones. Also, I can run the example project and add the default plugin. All it works. I used a clean installation and tried running cargo clean, but none of that helped me.

i use 23H2 Windows ver. OS 22631, 4602 build

[skimmedsquare]

Just a note that I can't repro the crash with the example code on Mac.

[BenjaminBrienen]

Can't reproduce

[jmskov]

Are your GPU drivers up to date? I would also try to reinstall the GPU driver.

[KeiMuriKoe]

Can't reproduce

I suspect this is related to my large list in Cargo.toml, but I haven’t added anything that isn’t in the Quick Start section of the Bevy docs.I also used cargo update to get version 0.15.1, and it seems to have worked, but for some reason, Cargo.toml still shows 0.15.0.

[PhantomMorrigan]

Try disabling dynamic linking, maybe? (Just a guess)

[BenjaminBrienen]

Can you please post your Cargo.toml?

[copygirl]

@KeiMuriKoe From the screenshot I can see you depend on bevy version 0.15 which is equivalent to >=0.15.0, <0.16.0, so it's not surprising it updated to a newer version. The same would happen if you specified 0.15.0. See here.

[eidloi]

@KeiMuriKoe There is an issue with wgpu on Windows where you get this error. In my case my laptop has both a dedicated and an iGPU and I had to specify to always use the dedicated GPU in the Nvidia driver settings (by default it just "picks the best" for the process / power saving scheme). I recall there is a similar setting for AMD GPUs as well (the Windows setting didn't work for me), perhaps you can try to look for that.

edit: this is the ticket I pinged but couldn't yet follow up: gfx-rs/wgpu#5879
There is also an AMD specific bug open: gfx-rs/wgpu#6329 but I don't think an empty project would trigger that issue since it's shader-related

[KeiMuriKoe]

Can you please post your Cargo.toml?

no problem

name = "my_bevy_game"
version = "0.1.0"
edition = "2021"

[dependencies]
bevy = { version = "0.15", features = ["dynamic_linking"] }
log = { version = "*", features = ["max_level_debug", "release_max_level_warn"] }

[profile.dev]
opt-level = 1

[profile.dev.package."*"]
opt-level = 3

[workspace]
resolver = "2" # Important! wgpu/Bevy needs this!

[profile.release]
codegen-units = 1
lto = "thin"

[profile.wasm-release]
inherits = "release"
opt-level = "s"
strip = "debuginfo"

edited : As I mentioned earlier, I didn’t add anything that wasn’t already in Bevy’s quick start guide. I only included everything suggested for optimizing the program's compilation time.

[KeiMuriKoe]

@KeiMuriKoe There is an issue with wgpu on Windows where you get this error. In my case my laptop has both a dedicated and an iGPU and I had to specify to always use the dedicated GPU in the Nvidia driver settings (by default it just "picks the best" for the process / power saving scheme). I recall there is a similar setting for AMD GPUs as well (the Windows setting didn't work for me), perhaps you can try to look for that.

edit: this is the ticket I pinged but couldn't yet follow up: gfx-rs/wgpu#5879 There is also an AMD specific bug open: gfx-rs/wgpu#6329 but I don't think an empty project would trigger that issue since it's shader-related

Sounds very interesting! What do I need to do to test this hypothesis?
I tried removing the line [workspace] resolver = "2" # Important! wgpu/Bevy needs this!
from the Cargo.toml file and used cargo run — it didn’t help.
I also tried cargo clean followed by cargo run again — that didn’t work either.

[KeiMuriKoe]

@KeiMuriKoe From the screenshot I can see you depend on bevy version 0.15 which is equivalent to >=0.15.0, <0.16.0, so it's not surprising it updated to a newer version. The same would happen if you specified 0.15.0. See here.

Oh. THX YOU! REally helpful information

[KeiMuriKoe]

Try disabling dynamic linking, maybe? (Just a guess)

I don’t know who you are, hero. Honestly, I tested your theory last, thinking there’s no way it would work… How wrong I was. By removing just one line, features = ["dynamic_linking"] it started working.

[KeiMuriKoe]

Is it ok? If not - waiting room for someone reproduce it

[PhantomMorrigan]

Okay, could you give some info on your installed rust toolchain?

[KeiMuriKoe]

Okay, could you give some info on your installed rust toolchain?

I’m not entirely sure what you mean by "toolchain." Perhaps you mean this: I installed the latest MSVC, the latest Windows SDK, and the C++ CMake tools for the Windows component.

[PhantomMorrigan]

What I mean is the info you are given by running rustup show. Would be really helpful.

[KeiMuriKoe]

What I mean is the info you are given by running rustup show. Would be really helpful.

Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\Den\.rustup

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc (default)
nightly-x86_64-pc-windows-msvc

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (overridden by 'D:\apps\bevy projects\my_bevy_game\rust-toolchain.toml')
rustc 1.85.0-nightly (45d11e51b 2025-01-01)

[PhantomMorrigan]

try running rustup update, and check if the error still occurs with dynamic linking?

[KeiMuriKoe]

rustup update

It didn't help.

[jmskov]

Try running rustup default stable or change D:\apps\bevy projects\my_bevy_game\rust-toolchain.toml to use the stable toolchain instead of the nightly build to rule out a problem there.

[KeiMuriKoe]

Try running rustup default stable or change D:\apps\bevy projects\my_bevy_game\rust-toolchain.toml to use the stable toolchain instead of the nightly build to rule out a problem there.

[jmskov]

Tried on my PC w/ 6900XT GPU, no issues. Here is my GPU driver info from running the game:

[PhantomMorrigan]

The example code doesn't add any plugins, and thus doesn't interact with the GPU.

[KeiMuriKoe]

Tried on my PC w/ 6900XT GPU, no issues. Here is my GPU driver info from running the game:

did you use dynamic_linking?

[jmskov]

Yes, I used dynamic_linking and the other features in your Cargo.toml.

[0not]

TL;DR: My next comment has a minimally reproducible example showing that the issue persists with default-features = false for bevy on two different Windows machines (10 and 11).

I can reproduce this issue when compiling with --release and dynamic linking with LLD on Windows 11. Debug builds work fine. Disabling dynamic linking also works fine. Dynamic linking with the default linker DOES NOT work, with a slightly different error (no output and process did not end without CTRL+C).

Device and OS details:

Processor	AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics     3.30 GHz
Installed RAM	32.0 GB (30.7 GB usable)

Edition	Windows 11 Pro
Version	23H2
Installed on	‎12/‎7/‎2023
OS build	22631.4751
Experience	Windows Feature Experience Pack 1000.22700.1055.0

Output of rustup show:

> rustup show                                               
Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\xxxxxx\.rustup

stable-x86_64-pc-windows-msvc (default)
rustc 1.84.0 (9fc6b4312 2025-01-07)

Minimal reproducible example:

use bevy::prelude::*;

fn main() {
    // Program executes correctly if I don't add a system
    App::new().add_systems(Update, setup).run();
}

fn setup() {
    println!("Setup");
}

Error when dynamic linking is enabled with LLD (and --release):

    Finished `release` profile [optimized] target(s) in 2.72s
     Running `target\release\examples\custom_schedule.exe`
error: process didn't exit successfully: `target\release\examples\custom_schedule.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

Error when dynamic linking is enabled with default linker (and --release). I had to hit CTRL+C to quit the process because the process ran without any output and did not exit.

    Finished `release` profile [optimized] target(s) in 6m 22s
     Running `target\release\examples\custom_schedule.exe`
error: process didn't exit successfully: `target\release\examples\custom_schedule.exe` (exit code: 0xc000013a, STATUS_CONTROL_C_EXIT)

I am running this in an example that is part of a workspace.

Workspace Cargo.toml

[workspace]
resolver = "2" # Needed for wgpu/Bevy
members = [ "xxxx" ]


# Enable a small amount of optimization in the dev profile.
[profile.dev]
opt-level = 1

# Enable a large amount of optimization in the dev profile for dependencies.
[profile.dev.package."*"]
opt-level = 3

# Enable more optimization in the release profile at the cost of compile time.
[profile.release]
# Compile the entire crate as one unit.
# Slows compile times, marginal improvements.
codegen-units = 1
# Do a second optimization pass over the entire program, including dependencies.
# Slows compile times, marginal improvements.
lto = "thin"

# Optimize for size in the wasm-release profile to reduce load times and bandwidth usage on web.
[profile.wasm-release]
# Default to release profile values.
inherits = "release"
# Optimize with size in mind (also try "z", sometimes it is better).
# Slightly slows compile times, great improvements to file size and runtime performance.
opt-level = "s"
# Strip all debugging information from the binary to slightly reduce file size.
strip = "debuginfo"

Crate Cargo.toml (the extra dependencies are not relevant to the example, but perhaps with dynamic linking they matter):

[package]
name = "xxxxx"
version = "0.1.0"
edition = "2021"

[dependencies]
bevy = { version = "0.15", features = ["dynamic_linking"] }
bevy-inspector-egui = "0.28.1"
iyes_perf_ui = { git = "https://github.com/IyesGames/iyes_perf_ui.git" }
rand = "0.8.5"

And finally, my .cargo/config.toml:

[env]
# Eliminates ERROR messages relating to D3D12 on Windows
# Full error:
# ERROR wgpu_hal::auxil::dxgi::exception: ID3D12CommandQueue::ExecuteCommandLists: Using IDXGISwapChain::Present on Command List (0x000002AA96478D20:'Internal DXGI CommandList'): Resource state (0x464FF090: D3D12_RESOURCE_STATE_RENDER_TARGET) of resource (0x000002AA964E9EE0:'Unnamed ID3D12Resource Object') (subresource: 0) is invalid for use as a PRESENT_SOURCE.  Expected State Bits (all): 0x464FF070: D3D12_RESOURCE_STATE_[COMMON|PRESENT], Actual State: 0x464FF050: D3D12_RESOURCE_STATE_RENDER_TARGET, Missing State: 0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT]. [ EXECUTION ERROR #538: INVALID_SUBRESOURCE_STATE]
WGPU_BACKEND = "vulkan"

# for Linux
[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=lld"]


# for Windows
[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"

Summary

I cannot run programs compiled with --release with bevy/dynamic_linking enabled. This is true for both LLD and the default linker on Windows 11. If I don't add a system, everything works fine (program runs and exits with no error).

I'm going to try a clean project and report back.

[0not]

I set up a new project with the following Cargo.toml

[package]
name = "bevy_test"
version = "0.1.0"
edition = "2021"

[dependencies]
bevy = { version = "0.15", default-features = false, features = ["dynamic_linking"] }

The rust code did not change:

use bevy::prelude::*;

fn main() {
    App::new().add_systems(Update, setup).run();
}

fn setup() {
    println!("Setup");
}

Results:

> cargo run --release
    Finished `release` profile [optimized] target(s) in 0.18s
     Running `target\release\bevy_test.exe`
Setup

Next I tried adding the following to Cargo.toml:

[profile.release]
lto = "thin"

And ran into the error where the program runs but does not print "Setup". (I'm using the default linker.)

After switching back to LLD:

> cargo run --release
    Finished `release` profile [optimized] target(s) in 0.23s
     Running `target\release\bevy_test.exe`
error: process didn't exit successfully: `target\release\bevy_test.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

Summary

Dynamic linking does not work (with either LLD or the default linker) if lto = "thin" in the release profile.

What does this bug indicate? Why do the two linkers behave slightly differently? Should we report this elsewhere, or is it a bug with bevy?

EDIT: I can reproduce this on a Windows 10 PC.

Processor	AMD Ryzen 7 3700X 8-Core Processor                3.59 GHz
Installed RAM	32.0 GB


Edition	Windows 10 Pro
Version	22H2
Installed on	‎3/‎16/‎2021
OS build	19045.5371
Experience	Windows Feature Experience Pack 1000.19060.1000.0

[0not]

I have created a repository with an Action that reproduces this error:
https://github.com/0not/bevy_thinlto_error

Here is a log of the job that failed, though it's not super insightful:
https://github.com/0not/bevy_thinlto_error/actions/runs/13082447979/job/36508558427

My Rust debug skills are not up to digging any further into this. I'm not even able to get a backtrace.

The following may be relevant: #11446, rust-lang/rust#111480, rust-lang/rust#122790