Guide: Diagnosing a complete lack of output on Windows

I have now encountered this bug a few times in the wild so I thought it would be worth documenting. Hopefully it can serve as a reference.

The symptoms

Occasionally, Windows users will run into an issue where a CmdStan model compiles just fine, but running it produces no output. It doesn’t make a file, it doesn’t print anything, it just immediately exits. With cmdstanr, this leads to a error like here :

Warning: Chain 1 finished unexpectedly!
Warning messages:
1: All chains finished unexpectedly! Use the $output(chain_id) method for more information.
2: No chains finished successfully. Unable to retrieve the fit.

Additionally, the $output() method it recommends will be completely empty.

The diagnosis

There are potentially other issues which could lead to these errors, but one I have encountered several times is due to another copy of Intel’s Threaded Building Blocks (TBB) library being installed on the machine, and the Stan model trying to dynamically link to that copy instead of the one provided by Stan-math.

Checking this is, luckily, very easy, using a built-in command called where.exe.

Running the command

where.exe tbb.dll

Will search the Windows %PATH% for instances of that file, which is exactly what the dynamic linker does. The output can tell you several things:

  1. If there are no files found, then tbb.dll is not in your path (most likely, CmdStanR/Py are adding it at runtime). The issue you are having is not the one described in this thread, but adding TBB to your path might fix whatever issue you are having.
  2. If there is 1 file found, and it lives inside your $CMDSTAN folder, the issue you are having is not the one described in this thread.
  3. Finally, if you have more than 1 file found, or 1 file found but it is not from $CMDSTAN, then you’re in the case covered by this thread. In my experience, the “other” TBB is often in C:\system32\


Fundamentally, the way to fix this problem is to make Stan’s tbb.dll be the one which is accessed first. There are several options, depending on your level of permissions on your own machine and personal feelings:

  1. The local directory is always searched before the %PATH%, so you can copy Stan’s tbb.dll to the same folder as your model .exe and it will use that. Do this FIRST to make sure the issue goes away before considering any more extreme option.

  2. If the other TBB is on your PATH but not in system32 (which is always searched before the rest of the PATH), it’s possible to place Stan’s copy higher up on your path and then it should be picked up. You probably can do this temporarily from inside your favorite programming language that you’re using to call the model.

  3. If you know where the other tbb.dll came from, you may feel comfortable uninstalling/deleting it. NOTE: this WILL break any software which relied on the other TBB, so make sure you know what you’re doing, and possibly make a back up. If you don’t know where it came from, DO NOT DELETE IT

The explanation

CmdStan currently relies on gcc-on-Windows from the MinGW project to compile our C++ code, including the TBB library. If a user has another tbb.dll installed, it is almost assuredly compiled with the Microsoft Visual Studio compilers. This results in there being two shared libraries which are not interchangeable, since they’re compiled against different ABIs, but the dynamic linker has no way to tell them apart or pick one over the other.

Unfortunately, it seems like the dynamic linker failing in this way produces no helpful output and no errors.


@charlesm93 this is the post I mentioned during last week’s Stan meeting

1 Like