ID 141721 - Enabling the Write node's autocrop knob can cause the rendered pixel at (0,0) to have NaN or non-zero RGBA values

Problem summary:
Enabling the Write node's autocrop knob can cause the rendered pixel at (0,0) to have NaN or non-zero RGBA values

This has been observed to affect both 16 and 32 bit EXR files, but does not seem to impact macOS.

Customer reported version:
Nuke 14.1v5

Customer reported platform:
CentOS 7

Steps to reproduce (Linux):
1) Launch Nuke and create a Constant node in the Node Graph
2) In its properties, set the channels knob to RGBA
3) Create a Write node and set its file knob to a EXR that doesn't already exist and enable autocrop
4) Render this black frame
5) Read the EXR into Nuke and View it, and observe how the pixel at (0,0) has non-zero values
Note: Occasionally it is necessary to render the frame multiple times before the issue occurs

Steps to reproduce (Windows):
1) Launch Nuke and create a Constant node in the Node Graph
2) Create a Write node, and set its file knob to a EXR that doesn't already exist and enable autocrop
3) Render this black frame
4) Set the Constant's color to something other than 0, such as 1
5) Render the frame again 
6) Set the Constant's color back to 0
7) Render the frame again
8) Read the EXR into Nuke and View it, and observe how the pixel at (0,0) has non-zero values

Expected behavior:
The pixel at (0,0) should have 0 for its RGB(A) values, and there should not be any NaN pixels.

Actual behavior:
NaN and other unexpected values (such as 8.6e-06, 32768.00, -386.5) can be written out for the pixel at the origin (0,0).

Workaround:
No known workaround at this time.

Reproduced by Support in:
Nuke 16.0v6 - Windows 11, Rocky 9
Nuke 15.0v1 - Windows 11, Rocky 9
Nuke 14.0v1 - Windows 11, CentOS 7
Nuke 13.0v1 - Windows 11, CentOS 7

Unable to reproduce in:
Nuke 16.0v6 - macOS 14 Sonoma (ARM), macOS 14 Sonoma (Intel)

Earliest version tested:
Nuke 13.0v1 - This issue appears to be in all tested versions of the product