Nvidia driver update - reactor node

Beginners
1

I updated my Nvidia drivers today prompted by comfyui not starting and showing a message to update to the latest drivers.

Since then, Comfyui is breaking more often than normal.. the ‘browser refresh’ message appears during a video generation about 3 out of 10 times. Also, although it was never great, reactor has simply stopped working completely even after a re-install through the Manager. when it did work almost every vid was hitting the NSFW block even though the content was nothing more than an adult kiss so I gave up with it anyway

I tried to install the NSFW version of reactor but that failed miserably, something to do with cuda, light sowething, dlls and wheels.. far too complex to understand and chatgpt had no clue… almost ruined my entire PC build with it’s hopeless ability to be used as a diag tool

Anyway, rant over, is anyone else experiencing these issues and/or knows a path to fix ? Many thanks in advance

2

Hmm, it looks like ReActor can be quite fragile around ComfyUI updates:

I do not think this is simply “the NVIDIA driver update broke ReActor.”

My guess is that your environment is now in a mixed state:

ComfyUI was updated or moved to a newer Python / PyTorch / CUDA stack
↓
The new ComfyUI stack required a newer NVIDIA driver
↓
The driver update made the base ComfyUI stack partially usable again
↓
But ReActor still depends on ONNX Runtime GPU / CUDA DLLs / cuDNN / Python wheels
↓
Those ReActor-side dependencies no longer match cleanly
↓
Trying an NSFW fork or another ReActor variant probably made the Python environment more mixed

So the problem is probably not one single thing. It is more likely a combination of:

  • ComfyUI base stack change
  • NVIDIA driver requirement
  • PyTorch CUDA version
  • ONNX Runtime GPU provider
  • CUDA / cuDNN DLL loading
  • ReActor install script / Python environment
  • possibly a fork or NSFW variant modifying dependencies
  • video workflow instability on top of that

That is why reinstalling only the NVIDIA driver, or only reinstalling ReActor from Manager, may not fix it.

The important distinction

There are two different GPU stacks involved here:

ComfyUI / PyTorch stack:
  used for most image generation

ReActor / ONNX Runtime stack:
  used for face analysis / face swap / face restore paths

These can break independently.

So this can happen:

torch.cuda.is_available() == True
ComfyUI can generate images
but ReActor still fails
because ONNX Runtime CUDAExecutionProvider is broken

That is a common source of confusion.

Why the driver update may have been necessary

The current ComfyUI Windows portable documentation says the portable build includes Python 3.13 and PyTorch CUDA 13.0, and it tells users to update NVIDIA drivers if ComfyUI does not start:

For CUDA 13.x, NVIDIA’s compatibility table requires a 580+ NVIDIA driver:

So updating the driver was probably reasonable.

But the driver is only one layer. ReActor can still fail if ONNX Runtime GPU, cuDNN, CUDA DLLs, or Python wheels are mismatched.

Why ReActor specifically can break after updates

ReActor is not just a simple ComfyUI node. It pulls in a separate face-processing stack.

Relevant docs and reports:

ONNX Runtime’s CUDA provider documentation is especially important because it explains that CUDA and cuDNN major versions must match the ONNX Runtime build. In particular, cuDNN 8.x and cuDNN 9.x builds are not interchangeable.

That means ReActor can fail even if the rest of ComfyUI looks okay.

There are also similar ReActor failure reports:

These are not all exactly the same as your case, but they show the same general pattern: ReActor can break when ComfyUI, Python, PyTorch, ONNX Runtime, CUDA, cuDNN, and custom-node updates move together.

I would not keep repairing the current folder in-place

Because you already tried several things, the current environment may be hard to reason about.

It may now contain some combination of:

official ReActor
old ReActor files
Manager-installed files
fork / NSFW variant files
onnxruntime
onnxruntime-gpu
changed numpy / opencv / protobuf / insightface packages
possibly packages installed into system Python
possibly packages installed into ComfyUI embedded Python

At that point, it is very hard to know which layer is broken.

So I would not keep pressing random fixes in the current folder.

I would do this instead:

1. Preserve the broken folder as a backup
2. Create a clean updated ComfyUI portable install next to it
3. Confirm the clean ComfyUI base works
4. Confirm PyTorch CUDA works
5. Move models only
6. Install official ReActor only
7. Verify ONNX Runtime providers
8. Test ReActor on one still image
9. Only then move old workflows and video nodes back

This is usually faster than trying to surgically repair a mixed Python environment.

Recommended recovery path

Step 0: Stop changing the broken install

Rename the current folder, but do not delete it:

ComfyUI_windows_portable
->
ComfyUI_windows_portable_broken_backup

Keep it because it may contain:

models/
input/
output/
user/
workflows/
ReActor face models
logs
custom-node list

But do not copy these wholesale into the new install:

python_embeded/
custom_nodes/

Especially do not copy python_embeded. If that environment is already mixed, copying it transfers the problem.

ComfyUI Portable uses its own embedded Python environment:

So the Python environment matters a lot.

Step 1: Save a diagnostic snapshot of the broken install

From the broken folder, run:

cd C:\path\to\ComfyUI_windows_portable_broken_backup

nvidia-smi > recovery-baseline.txt

.\python_embeded\python.exe -c "import sys; print(sys.version)" >> recovery-baseline.txt

.\python_embeded\python.exe -c "import torch; print('torch=', torch.__version__); print('torch cuda=', torch.version.cuda); print('cuda available=', torch.cuda.is_available()); print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'no gpu')" >> recovery-baseline.txt

.\python_embeded\python.exe -c "import onnxruntime as ort; print('ort=', ort.__version__); print('providers=', ort.get_available_providers())" >> recovery-baseline.txt

.\python_embeded\python.exe -m pip freeze > pip-freeze-broken.txt

If some of these fail, that is okay. The failure itself is useful information.

Step 2: Verify the NVIDIA driver once

Run:

nvidia-smi

Check the driver version.

If your ComfyUI portable build is the new CUDA 13.0 one, the driver should be 580+ according to NVIDIA’s CUDA compatibility table:

Do not keep reinstalling drivers repeatedly. Verify it once, then move on.

Also note: the CUDA Version shown by nvidia-smi is the maximum CUDA API version supported by the driver. It is not necessarily the same as the CUDA version used by PyTorch inside ComfyUI. For that, use torch.version.cuda.

Step 3: Create a fresh ComfyUI portable install

Create a clean folder, for example:

C:\AI\ComfyUI_clean\

At this stage, do not install:

ReActor
ReActor NSFW fork
video custom nodes
old custom_nodes
old python_embeded

Start clean ComfyUI with custom nodes disabled:

cd C:\AI\ComfyUI_clean

.\python_embeded\python.exe -s ComfyUI\main.py --disable-all-custom-nodes --windows-standalone-build

ComfyUI documents this troubleshooting method here:

Then run a very basic built-in image workflow.

At this point you are only testing:

driver
ComfyUI base
embedded Python
PyTorch
basic image generation

You are not testing ReActor yet.

If this fails

If clean ComfyUI cannot generate one basic image, stop. ReActor is not the problem yet.

If this works

Then the base environment is probably good, and you can move to ReActor later.

Step 4: Verify PyTorch CUDA in the clean install

In the clean folder:

cd C:\AI\ComfyUI_clean

.\python_embeded\python.exe -c "import torch; print('torch=', torch.__version__); print('torch cuda=', torch.version.cuda); print('cuda available=', torch.cuda.is_available()); print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'no gpu')"

You want:

cuda available = True
GPU name printed

Reference:

If torch.cuda.is_available() is false, do not install ReActor yet. Fix the base GPU/PyTorch/driver problem first.

Step 5: Move models, not the entire old environment

Move or share only the model files.

Typical folders:

models/checkpoints/
models/vae/
models/clip/
models/clip_vision/
models/loras/
models/controlnet/
models/upscale_models/
models/diffusion_models/
models/text_encoders/
models/insightface/
models/reactor/

If the models are large, use extra_model_paths.yaml instead of copying everything:

The goal is:

new clean program environment
+
old model files

not:

new clean program environment
+
old broken Python packages

Step 6: Install only the official ReActor

Use the official repository:

Install it into the clean ComfyUI:

cd C:\AI\ComfyUI_clean\ComfyUI\custom_nodes

git clone https://github.com/Gourieff/ComfyUI-ReActor

cd ComfyUI-ReActor

install.bat

Important: the installer must use the ComfyUI portable embedded Python.

If you see a prompt like this:

I couldn't find an embedded version of Python,
but I did find Python <version> in your Windows PATH.
Would you like to proceed with the install using that version? (Y/N)

I would answer N and stop.

That is very close to this failure mode:

For portable ComfyUI, using system Python is usually the wrong direction. You want packages installed into the ComfyUI instance you actually run.

Step 7: Check ONNX Runtime after ReActor install

Before opening your old workflow, run:

cd C:\AI\ComfyUI_clean

.\python_embeded\python.exe -c "import onnxruntime as ort; print('ort=', ort.__version__); print('providers=', ort.get_available_providers())"

Ideal result:

['CUDAExecutionProvider', 'CPUExecutionProvider']

If you only see:

['CPUExecutionProvider']

then ReActor may still import, but ONNX Runtime GPU is not working.

Also check whether both CPU and GPU ONNX Runtime packages are present:

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"

Be suspicious of a mixed state like:

onnxruntime
onnxruntime-gpu

The important documentation is here:

The key idea is:

PyTorch CUDA working does not automatically prove ONNX Runtime CUDA is working.

They are related, but not identical.

Step 8: Test ReActor with one still image

Do not test video first.

Do not test the old workflow first.

Do not turn on face restore / GPEN / Face Boost first.

Start with the smallest possible workflow:

Load Image
Load Image
ReActorFaceSwap
Save Image

Start with:

Face Restore: off
Face Boost: off
Video: off
Batch size: tiny

Then test in this order:

1. still image face swap
2. still image face swap + face restore
3. small image batch
4. short low-resolution video
5. normal video
6. face restore / boost / upscale in video

This order matters because some reports involve the restore/boost paths and CUDA DLL failures:

Step 9: Replace the ReActor node in old workflows

Do not simply open the old workflow and press Queue.

ReActor’s README says old workflow nodes may need to be deleted and re-added after updates, because node inputs or definitions can change:

So the safer process is:

open old workflow
delete old ReActor node
add new ReActor node from the current install
reconnect inputs
save as a new workflow
test on one image

This avoids confusing an old serialized node definition with a CUDA or ONNX problem.

Step 10: Bring video custom nodes back last

The “browser refresh” / reconnect symptom during video generation may be a separate issue from ReActor.

ComfyUI uses WebSocket communication for execution progress, node status, error/debug information, and queue updates:

If the backend process crashes, hangs, runs out of VRAM/RAM, or a custom video node throws an exception, the browser may appear to refresh or reconnect.

So test video in this order:

1. video workflow without ReActor
2. short low-resolution video without ReActor
3. short low-resolution video with ReActor
4. normal video with ReActor
5. face restore / boost / upscale only after that

If video fails without ReActor, ReActor is not the remaining main problem.

What I would avoid

Until the clean environment works, I would avoid:

ComfyUI Manager -> Update All repeatedly
installing several ReActor variants
mixing official ReActor with NSFW forks
copying old custom_nodes wholesale
copying old python_embeded
using system Python pip
running random pip install -U commands
testing directly with a large video workflow
enabling Face Boost / GPEN / restore in the first test

Especially avoid commands like this unless you know exactly why:

pip install -U onnxruntime-gpu numpy opencv-python torch

If you must use pip in ComfyUI portable, use the embedded Python for the specific ComfyUI install you are running:

C:\AI\ComfyUI_clean\python_embeded\python.exe -m pip <package>

not just:

pip <package>

ComfyUI custom-node dependency docs:

Success checklist

I would consider the updated environment repaired only after these are true:

nvidia-smi works
driver version is suitable for the ComfyUI CUDA stack
fresh ComfyUI portable starts
basic image generation works
torch.cuda.is_available() is True
ReActor imports without error
onnxruntime.get_available_providers() includes CUDAExecutionProvider
minimal still-image ReActor workflow works
old workflow works after replacing the ReActor node
short video workflow works without ReActor
short video workflow works with ReActor
full video workflow works

Short version

I would not try to keep repairing the current folder in-place.

I would:

1. rename the broken install and keep it as backup
2. install a fresh current ComfyUI portable
3. confirm basic ComfyUI + PyTorch CUDA first
4. move models only
5. install only official ReActor
6. verify ONNX Runtime providers
7. test one still image
8. replace old ReActor nodes in workflows
9. bring video workflows back last

That gives you the best chance of ending up with a properly updated environment instead of a half-rolled-back, half-updated one.

3

wow… very comprehensive… I take the point about a mixed up environment… makes sense

I did exactly as suggested, new install, all the tests and cmd commands appeared to work correctly with no errors and the basic reactor faceswap on a simple image also worked! However, I noticed the is the command window when using reactor
“2026-05-26 10:52:37.6787763 [E:onnxruntime:Default, provider_bridge_ort.cc:2369 onnxruntime::TryGetProviderInfo_CUDA] E:_work\1\s\onnxruntime\core\session\provider_bridge_ort.cc:1962 onnxruntime::ProviderLibrary::Get [ONNXRuntimeError] : 1 : FAIL : Error loading “D:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\onnxruntime\capi\onnxruntime_providers_cuda.dll” which depends on “cublasLt64_12.dll” which is missing. (Error 126: “The specified module could not be found.”)”

absolutely no idea how to fix this and chatgpt is hopeless at this stuff

4

Yeah, ONNX Runtime breaks quite easily after environment changes… switching it to CPU temporarily may be a good move. Maybe something like this?

That error is very informative. It means the clean reinstall probably helped, but ONNX Runtime’s CUDA provider is still not loading correctly.

This line is the key:

Error loading:
D:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\onnxruntime\capi\onnxruntime_providers_cuda.dll

which depends on:
cublasLt64_12.dll

which is missing.

So I would read the current state like this:

Clean ComfyUI install: probably OK
Basic PyTorch CUDA test: probably OK, if your earlier torch command passed
Basic ReActor still-image swap: works
ONNX Runtime CUDAExecutionProvider: broken or drifting
ONNX Runtime CPUExecutionProvider: probably being used as fallback

So this is not the same problem as before. You made progress.

Before, the whole environment was probably mixed. Now the problem looks narrower:

ReActor can run, but ONNX Runtime GPU acceleration cannot load the CUDA 12 DLLs it expects.

That missing cublasLt64_12.dll is a CUDA 12 cuBLAS runtime DLL. ONNX Runtime’s CUDA provider is trying to load it, and Windows cannot find it.

Similar ReActor reports:

Relevant ONNX Runtime docs:

Important caveat: this may be real GPU/runtime drift

I would not assume this is only a harmless warning.

It might be harmless if ReActor falls back to CPU and the output looks correct. But it might also mean the GPU execution layer genuinely drifted.

In other words, this could be real drift in the execution substrate:

GPU model / architecture
NVIDIA driver
PyTorch CUDA build
onnxruntime-gpu version
CUDA runtime DLLs
cuDNN runtime DLLs
Windows DLL search path
ComfyUI embedded Python environment

That matters because ONNX Runtime GPU support is sensitive to the exact combination of CUDA, cuDNN, Python, PyTorch, and GPU architecture.

So CPU mode is not “the final answer.” It is a stabilization and isolation step:

First: make ReActor work reliably on CPU.
Then: treat ONNX Runtime GPU as a separate optimization / migration problem.

This keeps you from breaking the clean install again while trying to fix GPU acceleration.

Why the face swap still worked

Because ONNX Runtime can often fall back to CPU.

So this can happen:

ONNX Runtime tries CUDAExecutionProvider
CUDA provider fails because a CUDA DLL is missing
ONNX Runtime continues with CPUExecutionProvider
ReActor still produces an image
console prints scary CUDA errors

That would explain:

simple ReActor image test works
but console shows cublasLt64_12.dll errors

The main downside may be speed.

But if later video or face-restore paths become unstable, then the broken CUDA provider may matter more.

First: capture the exact GPU/runtime state

Before changing packages again, I would record this:

cd D:\ComfyUI_windows_portable

nvidia-smi

.\python_embeded\python.exe -c "import sys; print('python=', sys.version)"

.\python_embeded\python.exe -c "import torch; print('torch=', torch.__version__); print('torch cuda=', torch.version.cuda); print('cuda available=', torch.cuda.is_available()); print('gpu=', torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'no gpu'); print('capability=', torch.cuda.get_device_capability(0) if torch.cuda.is_available() else 'no gpu')"

.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())"

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime torch nvidia cuda cudnn"

The GPU name and compute capability matter. For example, if someone is on a very new GPU architecture, old CUDA wheels or runtime packages can genuinely be wrong even if the code did not change.

So I would save this output somewhere before fixing anything.

Interpret the provider result

Run:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())"

Case A

providers= ['CUDAExecutionProvider', 'CPUExecutionProvider']

This means ONNX Runtime package-level CUDA support is present, but loading the actual CUDA DLLs may still fail at runtime.

Case B

providers= ['CPUExecutionProvider']

or:

providers= ['AzureExecutionProvider', 'CPUExecutionProvider']

This means ONNX Runtime is effectively CPU-only.

Case C

Error loading onnxruntime_providers_cuda.dll
missing cublasLt64_12.dll

This means onnxruntime-gpu is installed, but the CUDA 12 runtime DLL it expects is not findable.

Check for mixed ONNX Runtime packages

This is worth checking:

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"

A confusing state would be:

onnxruntime
onnxruntime-gpu

Ideally, for a clean CPU-only temporary state, you want only:

onnxruntime

For a clean GPU state, you want only:

onnxruntime-gpu

Mixed CPU/GPU ONNX packages can make debugging harder.

Safest short-term workaround: make ONNX Runtime CPU-only

Because the simple ReActor swap already works, I would probably stabilize first.

The idea is:

Remove broken ONNX Runtime GPU provider
Use CPU ONNX Runtime
Verify ReActor still works
Verify the cublasLt64_12.dll warning disappears
Then decide whether GPU acceleration is worth fixing

Commands:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu

.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime

Then verify:

.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())"

A good temporary result is:

providers= ['CPUExecutionProvider']

or sometimes:

providers= ['AzureExecutionProvider', 'CPUExecutionProvider']

Then restart ComfyUI and test the same simple ReActor face swap again.

If the warning disappears and the image still works, then you have a stable baseline:

ComfyUI works
ReActor works
ONNX Runtime uses CPU
no missing cublasLt64_12.dll warning

That is a good recovery state.

Not necessarily the final fastest state, but a good stable state.

Why CPU-only may be the right next move

Because you have already proven something important:

fresh install worked
basic commands worked
basic ReActor image swap worked

So the remaining issue is narrower:

ONNX Runtime GPU acceleration is not loading

That should be treated separately.

If you try to fix ONNX GPU immediately, you may end up changing:

onnxruntime-gpu
CUDA runtime packages
cuDNN packages
PyTorch
Windows PATH
NVIDIA driver
ReActor dependencies

all at once again.

That is exactly how the original mixed environment probably happened.

So I would first get a clean CPU baseline, then handle GPU acceleration as a second phase.

If you later want to fix ONNX Runtime GPU

Only do this after CPU ReActor is stable.

The goal would be:

Make onnxruntime-gpu able to find the CUDA 12 / cuDNN DLLs it expects.

There are several possible paths.

Option A: Try ONNX Runtime GPU with CUDA/cuDNN extras

ONNX Runtime documents installation forms that can bring CUDA/cuDNN runtime dependencies into the Python environment.

In ComfyUI portable, use embedded Python:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -m pip uninstall -y onnxruntime onnxruntime-gpu

.\python_embeded\python.exe -m pip install --upgrade "onnxruntime-gpu[cuda,cudnn]"

Then test:

.\python_embeded\python.exe -c "import onnxruntime as ort; ort.preload_dlls(); print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers()); ort.print_debug_info()"

Relevant docs:

But I would treat this as a second-phase experiment, not the immediate recovery step.

Option B: Preload PyTorch / NVIDIA DLLs before ONNX Runtime

ONNX Runtime documents that preloading DLLs can help it use CUDA/cuDNN DLLs from PyTorch or NVIDIA Python packages.

The basic idea is:

import torch
import onnxruntime

or:

import onnxruntime
onnxruntime.preload_dlls()

But whether this helps inside ComfyUI depends on when ReActor creates its ONNX Runtime sessions. If the custom node creates sessions before the preload happens, the preload test may work in a standalone command but not fix the node.

So this is useful for diagnosis, but not always a clean user-level fix.

Option C: Install CUDA runtime globally

You could install CUDA 12 runtime/toolkit so Windows can find cublasLt64_12.dll.

But I would not start there.

Global CUDA and PATH edits can make things harder to reason about. For ComfyUI portable, I would prefer keeping dependencies inside the portable Python environment where possible.

Do not confuse these two questions

There are now two separate questions:

Question 1:
Can ReActor work reliably at all?

Question 2:
Can ReActor use ONNX Runtime GPU acceleration?

You have probably answered Question 1: yes, at least for a simple still image.

Question 2 is still unresolved.

That means the practical recovery route is:

First stabilize ReActor CPU.
Then decide whether ONNX GPU is worth fixing.

What I would do next

My exact next steps would be:

1. Save the current command outputs
2. Confirm the simple ReActor still-image test works
3. Check ONNX Runtime providers
4. Remove onnxruntime-gpu
5. Install CPU onnxruntime
6. Restart ComfyUI
7. Confirm the cublasLt64_12.dll warning is gone
8. Test simple ReActor still image again
9. Test your real still-image workflow
10. Test short video
11. Only later try ONNX Runtime GPU again

Commands:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"

.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu

.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime

.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())"

Then restart ComfyUI.

How to interpret the result

Good temporary result

providers= ['CPUExecutionProvider']
ReActor still works
no cublasLt64_12.dll warning

Meaning:

You now have a stable CPU ReActor setup.
It may be slower, but it is clean.

Still noisy

cublasLt64_12.dll warning still appears

Then onnxruntime-gpu is probably still installed somewhere in the ComfyUI embedded Python environment, or another package is still importing the GPU provider.

Check again:

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"

ReActor stops working after CPU-only install

Then reinstall official ReActor using its installer:

cd D:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-ReActor

install.bat

But make sure it uses:

D:\ComfyUI_windows_portable\python_embeded\python.exe

not system Python.

Short version

Your new install probably worked.

The remaining error is probably:

ONNX Runtime GPU provider is broken or drifting
but ReActor can still run through CPU provider

So I would not reinstall everything again.

I would first stabilize ONNX Runtime as CPU-only:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu

.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime

Then test ReActor again.

If that works and the warning disappears, you have a usable recovery state.

After that, GPU acceleration can be treated as a separate ONNX Runtime / CUDA / cuDNN / GPU-architecture migration problem, not as the main ReActor recovery problem.

5

Again… very comprehensive…

Here’s where we are now..

Basic reactor (single image to image) works

More advance (image to video (81 frames) - runs but always seem to hit the NSFW detected and produces a black square - even though there is no nsfw, literally someone just walking - other than a bare leg!
onnxruntime 1.26.0

There are no error or warning messages in the command screen (cublasLt64_12.dll warning still appears) no message about this

So I guess this is progress

I notice there is a NSFW reactor node - should I try it?

6

should I try it?

Yeah. I think trying that direction is probably faster. For ONNX, if the current speed feels too slow, you can sort out the GPU side later:

At this point I would probably stop treating the cublasLt64_12.dll warning as the main blocker.

It is still a real issue, but it now looks like a performance / ONNX CUDA provider issue, not the thing preventing ReActor from working.

The current situation looks more like this:

Clean ComfyUI install: working
Basic ReActor still-image face swap: working
Video workflow: runs
ONNX Runtime CUDA provider: still not healthy
ONNX Runtime CPU fallback: probably working
Current visible blocker: black output / SFW checker / NSFW detector

So if the current speed is acceptable, I would leave ONNX alone for now.

Do not keep chasing CUDA DLLs yet. That path can easily re-break the clean install.

Relevant ONNX docs, for later:

The cublasLt64_12.dll warning basically means:

onnxruntime-gpu tried to load CUDAExecutionProvider
↓
onnxruntime_providers_cuda.dll needed cublasLt64_12.dll
↓
Windows could not find that CUDA 12 DLL
↓
CUDAExecutionProvider failed
↓
ReActor likely continued through CPUExecutionProvider

That is not ideal, but if ReActor runs and speed is tolerable, I would postpone it.

The more important problem now is probably the SFW checker

The current GitHub ReActor build is intentionally SFW-oriented. The README says it has a nudity detector to avoid use with 18+ content:

There are also reports where ReActor outputs black images because the SFW checker is too sensitive:

So if your workflow is now running but the result becomes black squares, that sounds less like “ReActor is broken” and more like:

ReActor works
but the SFW / NSFW checker is blocking the output

If the checker is the real blocker, then trying to fix ONNX GPU first probably will not solve the black output.

I would not modify the now-working install directly

The current install is valuable because it works.

I would back it up before doing anything else.

For example:

ComfyUI_windows_portable
->
ComfyUI_windows_portable_sfw_working_backup

Then create a second copy for experiments:

ComfyUI_windows_portable_reactor_experiment

Use one as the stable backup, and one as the test install:

ComfyUI_windows_portable_sfw_working_backup
  = known working clean/SFW install

ComfyUI_windows_portable_reactor_experiment
  = experimental ReActor install

Do not test alternative ReActor builds inside the only working install.

That is how the environment can get mixed again.

Why I would separate the installs

ReActor-related installs can modify or depend on packages such as:

onnxruntime
onnxruntime-gpu
opencv
numpy
protobuf
insightface
transformers
timm
face restore packages

If multiple ReActor variants are installed together, it becomes hard to know which one is loading and which dependency changed.

So I would avoid this:

official ComfyUI-ReActor
+ old reactor node
+ forked reactor node
+ Manager-installed reactor
+ manual clone reactor

Instead, in the experiment copy, keep one ReActor variant at a time.

That is the main rule.

Share models instead of copying everything

If disk space is an issue, you do not have to duplicate all models.

ComfyUI supports extra_model_paths.yaml for sharing model folders between ComfyUI installs:

So the structure can be:

D:\AI\Models\
  checkpoints\
  vae\
  loras\
  controlnet\
  insightface\
  reactor\

D:\ComfyUI_windows_portable_sfw_working_backup\
D:\ComfyUI_windows_portable_reactor_experiment\

Then point both ComfyUI installs to the shared model directory.

This keeps the program environments separate while avoiding huge duplicate model folders.

Suggested practical path

I would do this:

1. Keep the current install as a backup.
2. Do not fix ONNX GPU right now.
3. Do not run Manager Update All.
4. Make a second ComfyUI copy for ReActor experiments.
5. In the experiment copy, remove/disable other ReActor variants.
6. Install/test only one ReActor variant at a time.
7. Test one still image first.
8. Test one extracted video frame.
9. Test a tiny 5–10 frame video.
10. Only then test the full 81-frame workflow.

The test order matters.

Do not start with the full video workflow.

Use this order:

still image
↓
one problematic extracted frame
↓
several extracted frames
↓
very short video
↓
full video

How to interpret the result

If the experimental ReActor build works on still images

Good. Then the base face swap path is healthy.

If it works on extracted frames

Then the SFW checker was probably the main blocker.

If extracted frames work but video fails

Then the issue is probably video pipeline integration, batch handling, frame order, or memory pressure.

If it fails even on a still image

Then the experimental install itself is not healthy yet.

Keep ONNX GPU as a later task

I would treat the ONNX warning like this:

Known issue:
  ONNX Runtime CUDAExecutionProvider cannot load cublasLt64_12.dll.

Current workaround:
  Let ReActor run through CPU fallback if speed is acceptable.

Later optimization:
  Fix onnxruntime-gpu / CUDA / cuDNN only if CPU speed is too slow.

Do not combine these two projects:

Project A:
  get a ReActor build that does not black out the output

Project B:
  restore ONNX Runtime GPU acceleration

Do Project A first.

Only do Project B later if needed.

One more caution

I would avoid manually patching random files inside the working install.

It is cleaner to preserve the working state and test a separate build/branch in a separate ComfyUI copy.

Also, obviously, this should only be used for content where you have the rights and consent to use the faces/images involved. Face-swap tooling can easily cross legal and ethical lines, so I would keep the test environment private and controlled.

Short version

I would do this:

Back up the current working install.
Leave ONNX GPU alone for now.
Use CPU fallback if the speed is acceptable.
Create a separate ComfyUI experiment copy.
Test a different ReActor build/branch there, not in the stable install.
Keep only one ReActor variant in that copy.
Test still image → extracted frame → short video → full workflow.

If that solves the black output, then the SFW checker was probably the real blocker.

If it does not, then the next target is the video pipeline, not ONNX CUDA.