This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(108.80000000000001, 91%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETV%3C/text%3E%3C/svg%3E)
Hello,
Since last windows 11 update (24H2), we observe slight differences between our continuous integration (WinServer 2022 21H2) and our develpers computers regarding some of our double precision calculation.
We checked iteratively versions of windows to clearly identify this was introduced when updating to 24H2, using the same binary yield different results thus failing our unit tests since we expect a deterministic result and binary exact equality (e.g dumping a value / re-reading it shall be binary equal).
But what's is interesting is that it do not happen with all our tests, so probably due to special float handling.
Note that :
I didn't find anything regarding this in release notes or forums except this Post (Changes to SEH on Windows 11 24H2 causing problems) more or less related.
Also I don't yet have a minimal reproducible code to share as I didn't find the exact culprit leading to this change still investigating, will update if I find something new.
Is this something that might happen between windows versions, or a bug fixed in 24H2 leading to this breaking change ?
Do you have any clue how to investigate this further or even a potential fix ?
Thanks for your time.
Have a nice day.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 13%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDR%3C/text%3E%3C/svg%3E)
the results changes at runtime
What exactly is meant by this? Is this, as an example, a statement of "I can observe the value in xmm0, but without doing anything floating point related or calling any functions, the value just changes."?
Having a precise description of what is going on would help in this case because of one unfortunate aspect of the CRT. As documented in Math and floating-point support, there is no guarantee of the correctly rounded result for an operation. Instead, the guarantee is that the result will mostly be within 1ULP of the correctly rounded result. There is also no guarantee of reproducable results on different CPUs.
This has two potential implications. The first is, if an algorithm with better accuracy becomes more feasable, then it is possible that this algorithm will be used. The second is that if a newer processor instruction set becomes available that provides better efficiency, then that will also be used. I don't think this will be rolled out as a smaller Windows update, but a big update, such as 24H2 is a perfect opportunity for these changes to come into effect.
Hi,
Thanks for your answer and support
Sorry if my statement was not clear enough, what I meant is that compilation wasn't involved at all and everything happening at runtime (but after reading here and there most of fp related operations are done at runtime so makes sense).
Running the binary twice on the exact same computer (at t time ) yields the same results. Running the binary on the exact same computer before and after upgrade to 24H2 yields different results.
It's clear something changed between both windows version (might be driver, or as you said some optimizations).
Following your suggestion regarding 1ULP comparison, I checked binary representation of the wrong result we're having, and its seems way more than 1ULP.
windows =24H2 result : 0011111010100001001010101010100000111101100101111000111010011111
windows <24H2 result : 0011111010011011110001100110111100000110011010111101101011110000
I'm not yet familiar enough with 1ULP concept but am I correct if I assume it shouldn't impact a sequence of float operations (add, substr, mult, etc...) and that the result of the sequence should still be within 1ULP ?
Note that tests that are successful (see below) matches exactly
To give a bit of a context in which case we observe this behaviour :
We have 1 test suite with 4 different cases, only one of them is failing.
In the 4 different cases, we have the following matrix :
| Mesh file | Algorithm | test result |
|---|---|---|
| File1 | Algo1 | failure |
| File1 | Algo1 | failure |
| File1 | Algo2 | success |
| File2 | Algo1 | success |
| File2 | Algo2 | success |
So from my understanding something happen in between File1 - Algo1 combination not yet identified.
During those tests, we want to perform a registration of a plane to another plane.
We open a mesh, read the triangles get some of the triangles and transform them into a pointcloud to serves as input of the algorithm.
We build a distance map from the triangle and use it in the cost function.
From there we try iteratively perform the registration of the points to the appropriate plane based on distance.
So there are some operations performed but nothing too fancy, we're just using Eigen::Matrix4d (inverse, mult mostly), and TriangleMesh class from Open3D read from an STL file. - everything is done on CPU side.
I don't know the natures of the algorithms / optimisations that could have been included into windows 24H2 or in a new intel microcode shipped with it and I think it's a good lead actually.
Do you know where I could find additional informations regarding this specific topic ? A detailed release note of windows 24H2, some driver / microcode version inspection or something like that.
Otherwise any way to rollback from 24H2 to 23H2 maybe ? Our target product is stuck on 22H2 for now and we need to ensure reproductability as much as possible.
I'll continue investigating on tests step by step reducing used samples or something like that if there are some "bad" triangles somewhere.
Thanks you for your time, have a nice day
CPU-Z where this bug hapens after upgrading.
Windows (Specs dump):
Windows 11 Pro Edition Version 24H2
OS Build 26100.2605
Windows Features Packs 1000.26100.36.0
Don't take in account first line in the table up there, not sure why copying from markdown gave this and too scared to edit (all separators disapeared :d)
Do these tests truncate the values to zero in case of underflows or inexact results using a SEH filter?
I'm not yet familiar enough with 1ULP concept but am I correct if I assume it shouldn't impact a sequence of float operations (add, substr, mult, etc...) and that the result of the sequence should still be within 1ULP ?
The only specific situation where I will state that there will be no difference is if there is only elementry operatrions (+ - × ÷) performed on hard coded floating point numbers. I am only somewhat confident that this also only applies to in range, aka not denormals.
Otherwise, depending on the relative exponents a 1ULP difference in one value doesn't mean that the entire calculation will be constrained to 1ULP. Multiplying a number by another that has a 1ULP variance and then subtracting from a number at the same exponent can result in a vastly different result, especially if the result of this subtraction is within the 1ULP or even inaccurate region of the two initial operands.
The reason why I'm not saying anything more here is due to the lack of information on the types of calculations occuring.
@viorel - sorry couldn't find your username in dropdown -
We don't use any kind of SEH filter nor specific operation on floating points except compiling with /fp:strict.
There's a lot going on in our process but I can assure we only use basic operations such as :
Conjugation, Inverse, Cholesky Decomposition that's all.
We do have some tests that uses std::sin or std::cos but they're not failing.
Anyway,we manage to reproduce a similar behaviour in a simple code sample using only matrix multiplication :
Code :
#include <gtest/gtest.h>
#include <iostream>
#include <iomanip>
#include <limits>
#include <Eigen/Core>
TEST(PointCloudUtilsTests, matrixMultiplication_equalExpected)
{
// store default env;
unsigned int originalControlWord = 0;
_controlfp_s(&originalControlWord, 0, 0);
// fixing fp control
unsigned int fpControlMask = FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW | FE_UNDERFLOW | RC_NEAR;
_controlfp_s(nullptr, ~fpControlMask, fpControl
Mask);
auto loadPointFromFile = [](const std::filesystem::path& p_path) -> std::vector<Eigen::Vector3d>
{
std::vector<Eigen::Vector3d> points;
std::ifstream file(p_path.string());
double x, y, z = 0;
while (file >> x >> y >> z)
{
points.emplace_back(x, y, z);
}
return points;
};
auto toMatrix = [](const std::vector<Eigen::Vector3d>& p_pointCloud) {
Eigen::MatrixX3d points(p_pointCloud.size(), 3);
std::cout << "Set of 3d points : " << std::endl;
for (int i = 0; i < p_pointCloud.size(); ++i)
{
Eigen::IOFormat fullPrecisionFmt(Eigen::FullPrecision);
std::cout << std::fixed << std::setprecision(std::numeric_limits<double>::max_digits10) << p_pointCloud[i].x() << " " << p_pointCloud[i].y() << " " << p_pointCloud[i].z() << std::endl;
points.row(i) = p_pointCloud[i];
}
return points;
};
const auto pointcloudFilePath = std::filesystem::path(__argv[0]).parent_path() / "pointcloud.txt";
ASSERT_TRUE(std::filesystem::exists(pointcloudFilePath));
const std::vector<Eigen::Vector3d> points = loadPointFromFile(pointcloudFilePath);
ASSERT_FALSE(points.empty());
const Eigen::MatrixX3d matrix = toMatrix(points);
const Eigen::Matrix3d covariance = matrix.transpose() * matrix;
Eigen::IOFormat fullPrecisionFmt(Eigen::FullPrecision);
std::cout << "Covariance matrix : " << std::endl;
std::cout << std::fixed << covariance.format(fullPrecisionFmt) << std::endl;
EXPECT_EQ(covariance.row(0), Eigen::Vector3d(37015361.39861094951629639, 65914992.65099146962165833, 504969830.10096740722656250).transpose());
EXPECT_EQ(covariance.row(1), Eigen::Vector3d(65914992.65099146962165833, 135128697.05431032180786133, 1018944393.48469054698944092).transpose());
EXPECT_EQ(covariance.row(2), Eigen::Vector3d(504969830.10096740722656250, 1018944393.48469054698944092, 7853173472.83890151977539062).transpose());
// restore
_controlfp_s(nullptr, originalControlWord, 0xFFFFFFFF);
}
Inputs:
Outputs:
Compiler:
Compile options :
/fp:strict /fp:except /permissive- /MP2 /EHsc /O2 /std:c++20 /DWIN32 /D_WINDOWS
External libraries used :
Hardware used : same hardware see above
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(80, 1%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJR%3C/text%3E%3C/svg%3E)
Dear Microsoft Support Team,
We also have observed consistent discrepancies since the release of Windows 11 24H2, with differing behaviors between debug and release builds.
One specific case we identified involves the tanh function, which now produces inconsistent results for certain inputs. For instance, the calculation:
tanh``(-``0.7487220554777398``) may return either -0.6343859299029105 or -0.6343859299029104.
While this is a specific example, we suspect that other mathematical functions might exhibit similar inconsistencies, although we have not yet pinpointed them.
In addition to these numerical discrepancies, we also detected changes in how JPEG files are processed. When loading JPEG files with GDI+ (gdiplus), the results now slightly differ from previous versions of Windows.
We are unsure if these issues are interconnected, but they appear to point to potential regressions or alterations in the underlying libraries or computation methods introduced in Windows 11 24H2.
We would greatly appreciate your assistance in investigating these issues further. If needed, we can provide additional details or reproduce the problem in a controlled environment to facilitate debugging.
Best regards,
Jérémie Blanc
Tech Lead at Digital Surf
It seems that the implementation of cos(), tanh(), etc... has changed in ucrtbase.dll, giving sometimes different results than before (and between release and debug).
@Jérémie Blanc
Just to ask, what is the version of the Windows SDK installed on the system that has that apparent difference between debug and release?
The debug version of the UCRT is installed with the Windows SDK, so if the system doesn't have the 26100 version of the Windows SDK installed, it will not have the 26100 version of the debug UCRT installed.
So is it possible that an older version of the debug UCRT is being used?