DEV Community

Marcus Rowe
Marcus Rowe

Posted on • Originally published at techsifted.com

Stable Diffusion Not Working? 9 Fixes for Common Errors (2026)

Stable Diffusion errors hit differently than cloud AI tools. There's no support chat, no status page, no customer service. When it breaks, it's you, a terminal window, and a stack trace.

I've debugged more Stable Diffusion installs than I want to count -- my own, friends', and through forum rabbit holes at midnight. The same issues come up constantly. Black images. CUDA OOM errors before you've even tried a real resolution. Installs that work perfectly for three days and then explode when you add a single extension.

Most of these problems have fixes. Not elegant fixes, but fixes. Here's how to work through the most common ones.


Fix 1: Black or Blank Images

You ran a generation, the progress bar moved, and you got a perfectly black image. Or pure gray. Or a single flat color.

This is almost always a VAE problem.

The VAE (variational autoencoder) is the component that decodes the latent image into actual pixels. Some models have a VAE baked in. Some don't -- they need an external VAE file, and if that file is missing or wrong, you get black.

The quick fix: In AUTOMATIC1111, go to Settings > Stable Diffusion and look at the VAE dropdown. If it's set to "None," change it to the vae-ft-mse-840000-ema-pruned.safetensors file. That VAE works for most SD 1.5 models. If you don't have it, download it from Hugging Face and drop it in stable-diffusion-webui/models/VAE/.

For SDXL models: Use the SDXL VAE (sdxl_vae.safetensors). The SD 1.5 VAE will not work for SDXL -- you'll get garbage output or black images.

For models with baked-in VAEs: Some models (anything labeled "with VAE" in the filename) include the VAE already. For these, set the WebUI VAE to "None" or "Automatic." Loading an external VAE on top of a baked-in one can actually make image quality worse.

One other black image cause that's less common: NaN (Not a Number) errors in the computation. This happens sometimes with very high or very low CFG scale values. If you're running CFG scale above 15 or below 2, try pulling it back toward 7 and see if that fixes it.


Fix 2: CUDA Out of Memory Errors

The CUDA OOM error has ruined more test runs than I can count.

RuntimeError: CUDA out of memory. Tried to allocate X.XX GiB...
Enter fullscreen mode Exit fullscreen mode

This means your GPU doesn't have enough VRAM for what you asked it to do. The fix is either to reduce what you're asking or to use memory optimization settings.

Reduce resolution first. SD 1.5 was trained at 512x512. Start there. Every doubling of resolution roughly quadruples VRAM usage. If you're trying 768x768 or higher with a 4GB card, you're going to hit OOM.

Reduce batch size. If you're generating multiple images at once (batch size > 1), set it to 1. Each image in a batch needs its own VRAM allocation.

Use AUTOMATIC1111's memory optimization flags. Add these to your webui-user.bat (Windows) or webui-user.sh (Linux/Mac) in the COMMANDLINE_ARGS line:

  • --medvram -- reduces VRAM usage significantly with modest speed impact
  • --lowvram -- reduces further, noticeable speed impact, for 4GB cards
  • --xformers -- memory-efficient attention, speeds up generation AND reduces VRAM

For a 6GB card running SD 1.5: --medvram --xformers is a solid default.

SDXL on limited VRAM: SDXL genuinely needs 8GB+ for standard 1024x1024 generation. There's no flag that makes it run well on 4GB. If you're on a 4GB card and want SDXL-quality output, look at distilled SDXL models like SDXL-Turbo or the various SDXL Lightning models -- they're optimized for lower VRAM usage.


Fix 3: Slow Generation (or It's Running on CPU)

Generation should take seconds on a GPU. If it's taking minutes per image, Stable Diffusion is almost certainly running on CPU.

Check the console output when AUTOMATIC1111 starts. You're looking for a line that says something like:

Model loaded on device: cuda:0 (NVIDIA GeForce RTX 3080)
Enter fullscreen mode Exit fullscreen mode

If you see cpu instead of cuda, that's the problem.

GPU not detected. Make sure PyTorch is installed with CUDA support. The default PyTorch install may not include CUDA. In AUTOMATIC1111, this is usually handled automatically by the install script -- but if you installed PyTorch separately or it got overwritten, run:

pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118
Enter fullscreen mode Exit fullscreen mode

(Replace cu118 with your CUDA version -- check with nvcc --version.)

Install xformers. This single change can speed up generation by 30-50% on many setups. Add --xformers to your launch arguments. If xformers isn't installed, AUTOMATIC1111 will ignore the flag and tell you in the console. Install it with pip install xformers.

Batch processing bottleneck. If generation speed is fine but you're waiting a long time between batches, the bottleneck may be model loading -- especially if you're switching between checkpoints frequently. Keep one model loaded and switch only when you actually need a different one.


Fix 4: Installation Failures

Fresh install that won't complete. Errors during pip install. The webui won't start after install.

Python version. AUTOMATIC1111 requires Python 3.10 or 3.11. Python 3.12 breaks several dependencies. Check your version with python --version or python3 --version. If you're on 3.12, install 3.10 or 3.11 alongside it and use the correct version when launching.

Git not found. The install script uses Git to clone repositories. If Git isn't in your system PATH, the install will fail with a confusing error. Download Git from git-scm.com and run the install script again after it's added to PATH.

Permission errors on Windows. Run webui-user.bat as a normal user, not as Administrator. Running as admin can cause Python and pip to install to the wrong locations, which breaks the virtual environment.

The install died halfway. Run it again. Seriously. The install script is idempotent -- it'll pick up where it left off and usually complete on a second run. If it fails three times in a row, look at the actual error message. It almost always points to a specific package. Search for that package name + the error text.

On Linux: Make sure you have the system dependencies. For Ubuntu/Debian:

sudo apt install wget git python3 python3-venv libgl1 libglib2.0-0
Enter fullscreen mode Exit fullscreen mode

Missing libgl1 causes silent failures that look like GPU detection issues.


Fix 5: Model Loading Errors

You downloaded a new checkpoint and AUTOMATIC1111 won't load it.

Wrong directory. Models go in stable-diffusion-webui/models/Stable-diffusion/. Embeddings go in embeddings/. LoRAs go in models/Lora/. Putting a LoRA in the main checkpoints folder won't work -- it won't show up in the checkpoint list because it's not a checkpoint.

Click the refresh button. AUTOMATIC1111 doesn't auto-detect new model files. After dropping in a new checkpoint, hit the small refresh icon next to the checkpoint dropdown. If it still doesn't appear, restart the WebUI.

Corrupted download. Check the file size. A real SD 1.5 checkpoint in safetensors format is around 2GB. A .ckpt version is around 4GB (it stores more data). If you downloaded a "2GB model" and the file is 500MB, the download failed. Re-download it.

safetensors vs .ckpt. Safetensors is the modern format and is generally safer (no executable code in the file). Some older models are only available as .ckpt. Both formats work fine, but if you have the choice, safetensors is preferred.

Model is from a newer version of SDXL or SD3. Not all models work with all WebUI versions. If a model flat-out won't load and the file looks intact, check the model's page (usually on CivitAI or Hugging Face) for version requirements. Some newer architectures need a newer AUTOMATIC1111 or specific extensions.


Fix 6: VAE Issues Beyond Black Images

The VAE causes a wider range of problems than just black output. Washed-out colors, extreme oversaturation, loss of fine detail in faces and text -- these are all often VAE mismatches.

Colors look wrong / washed out. If skin tones look grayish or everything looks like it's been desaturated, try a different VAE. The vae-ft-ema-560000-ema-pruned.safetensors is softer than the mse version -- some models pair better with one or the other.

Faces look broken or melted. This can be the VAE, but it's more often the model itself combined with low resolution. SD 1.5 faces at 512x512 look rough. Use the Hires fix (in AUTOMATIC1111's generation settings) to upscale after the initial generation -- it makes a massive difference for portraits.

Using SDXL refiner models. SDXL has a two-stage pipeline: a base model generates a latent, and the refiner polishes it. These are separate models that need to be configured as base + refiner, not loaded as standalone checkpoints. Loading the SDXL refiner as a main checkpoint produces garbage.


Fix 7: ControlNet Not Working

ControlNet is one of the most powerful Stable Diffusion extensions and one of the most confusing to troubleshoot because there are two separate things that need to work: the extension itself and the control model files.

Missing control models. Installing the ControlNet extension doesn't give you the models. You need to download them separately from Hugging Face (the lllyasviel/ControlNet-v1-1 repository has most of them). They go in extensions/sd-webui-controlnet/models/. Without the model files, ControlNet will show no options or fail silently.

Wrong model for the preprocessor. Each ControlNet type needs its matching model. OpenPose detection needs an OpenPose ControlNet model. Canny edge detection needs a Canny model. They're not interchangeable. Double-check that the model in the ControlNet panel matches the preprocessor you've selected.

ControlNet panel isn't showing up. Go to Extensions > Installed and make sure the ControlNet extension is enabled. If you just installed it, restart the WebUI. If the panel shows up but is greyed out, check that you have a control model selected.

Extension version mismatch. ControlNet updates frequently. An old version of the extension on a newer AUTOMATIC1111 can cause silent failures. Go to Extensions > Installed > Check for updates and apply any available updates.


Fix 8: AUTOMATIC1111 WebUI Errors

Some errors are specific to the WebUI layer, not the underlying model.

"No module named 'gradio'" on launch. This means the virtual environment didn't fully install. Delete the venv folder inside your stable-diffusion-webui directory and run the launch script again. It'll rebuild the venv from scratch.

Port already in use. AUTOMATIC1111 uses port 7860 by default. If something else is using that port (or a previous AUTOMATIC1111 instance that didn't close cleanly), add --port 7861 to your launch arguments to use a different port.

Extensions causing startup crashes. If the WebUI crashes immediately after showing extension loading, one of your extensions is broken. The fastest diagnosis: add --disable-all-extensions to your launch arguments temporarily. If it starts clean, start re-enabling extensions one at a time.

Settings got corrupted. If you're getting weird errors that don't match any of the above, delete config.json and ui-config.json from the stable-diffusion-webui directory. The WebUI will regenerate them with defaults on next launch. You'll lose your settings customizations but it often clears strange state.


Fix 9: ComfyUI Errors

ComfyUI is a node-based alternative to AUTOMATIC1111. Same underlying models, different interface, different failure modes.

Missing node errors. ComfyUI workflows often require custom nodes from various repositories. If you load a workflow and see red nodes with errors, you need to install those nodes. The ComfyUI Manager extension handles this -- install it first, then use its "Install Missing Custom Nodes" option when loading workflows that have missing nodes.

Model paths are different. ComfyUI looks for models in its own models/ subdirectory, organized differently from AUTOMATIC1111. If you already have AUTOMATIC1111 installed, you can point ComfyUI to the same model directories by editing ComfyUI/extra_model_paths.yaml. That way you don't need two copies of every model.

"ERROR: Could not connect to ComfyUI server." in the browser. The server didn't finish starting. Check the terminal window where you launched ComfyUI -- it should show an "Starting server" message followed by the URL. If it shows an error there, that's what needs fixing. Common cause: port conflict (default is 8188).

Workflow runs but produces a black image. Same VAE issue as AUTOMATIC1111. In ComfyUI, the VAE is loaded explicitly as a node. If there's no VAE Loader node in your workflow, or it's pointing to the wrong VAE file, you'll get black output. Add a VAE Loader node and connect it to your sampler.


If you're still stuck after working through this list, the r/StableDiffusion subreddit is genuinely helpful -- include your exact error message, your GPU, VRAM amount, and which WebUI you're using. That information matters for getting a useful answer.

Stable Diffusion's complexity is part of the deal. You get enormous flexibility and zero subscription fees, but you also get the entire debugging responsibility. Once it's working well on your hardware, though, it's an incredibly capable tool. Our best AI image generators roundup covers where Stable Diffusion sits relative to the cloud alternatives if you're evaluating tools. And if you're hitting persistent issues with cloud-based generators too, the Midjourney troubleshooting guide and Adobe Firefly troubleshooting guide cover those distinct failure modes.

Top comments (0)