Help with Fatal Internal Error 0x00CDDDE7: FPCODatainterface.cpp line 305

[cstorey]

I updated to LabVIEW 2025Q3 just before the xmas break.  All was working after the updates, but upon return I am unable to open certain VIs due to the error pictured below. 

It mainly affects larger complicated VIs.  Others load and run from the IDE just fine.   

Anyone else facing this issue?  Forum and Google searches haven't returned anything so I suspect it might be a partially corrupted update or anti-virus interference.  Any suggestions as I wait for full re-install?   

[cstorey]

Repaired my install, but same error.  Identical system with the same LabVIEW version installed works fine.  Very frustrating.

[Kyle97330]

If you look at your screenshot, note that you missed a letter.  The title of this post has "FPCODatainterface" in it, but the error message has "FPDCODatainterface" shown.  So searching for the wrong thing might not have been helping.

Even correcting for that, there's nothing for the whole error message, but if you just search for "FPDCO", there are a few hits in the forum, one of which states that it stands for "Front Panel Data Control Object":

https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/What-does-quot-FPDCO-data-is-not-initialized...

When this happens, do you get an entry in the crash logs, in "<your documents folder>\LabVIEW Data\LVInternalReports\LabVIEW"?  If so, did you check the text files there (inside the zip files) for clues?

Best guess would maybe be a corrupted VI that all those VIs share as a subVI somewhere, or maybe if you have "Separate compiled code" enabled you need to clear that cache (which I don't know if that would have been done on a reinstall...).

[cstorey]

Thanks for the ideas Kyle.  The spelling error, (good catch!) was the result of the forum automatic hints trying to correct me as I typed.  I've now disabled that feature!

Repairing the LabVIEW 2025Q3 install using NIPM hasn't fixed anything. I will try a complete re-install if there are no better suggestions, though that's long and painful!

The good new is that the VI is not corrupted.  A copy opens and runs just fine on an identical machine with 2025Q3.  I've also discovered a few other VIs which fail to open on one machine but work fine on the other.  I can't find a common VI between them that might cause the issue.  It seems to be larger more complicated VIs..  

So I'm a bit stumped.  I get the error on 1 of two identical systems, and on another laptop.  The other development systems load the VIs without complaint.

Here's the LVInternalReport text file..  Seems to suggest its related to a PXI UserDefinedRefObj ??

####
#Date: Jan 16, 2026 11:50:41 AM
#OSName: Windows 10 Enterprise
#OSVers: 10.0
#OSBuild: 22631
#AppName: LabVIEW
#Version: 25.3.3f3 32-bit
#AppKind: FDS
#AppModDate: 1/14/2025 15:45 GMT
#LabVIEW Base Address: 0x00BD0000

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 12 processors
InitExecSystem() call to GetNumProcessors() reports: 12 processors
InitExecSystem() will use: 12 processors
Resource cache generator must exist and be a file. C:\Program Files (x86)\National Instruments\LabVIEW 2025\Targets\NI\FPGA\bin\gen_res_cache_lvaddons.exe
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 8 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 9 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 10 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
starting LabVIEW Execution System 2 Thread 11 , capacity: 24 at [3851427049.39232016, (11:50:49.392320157 2026:01:16)]
UserDefinedRefObj wrong/mixed case sensitivity, refObj named: PXI2Slot5_2 tagType: 3
DPrintfCallChain: FindRefObjCore() wrong/mixed case sensitivity
UserDefinedRefObj wrong/mixed case sensitivity, refObj named: PXI2Slot5_2 tagType: 3
DPrintfCallChain: FindRefObjCore() wrong/mixed case sensitivity
UserDefinedRefObj wrong/mixed case sensitivity, refObj named: PXI2Slot5_2 tagType: 3
DPrintfCallChain: FindRefObjCore() wrong/mixed case sensitivity

<DEBUG_OUTPUT>
2026-01-16 11:51:03.634 AM
DAbort 0x00CDDDE7: FPDCODataInterface::GetOperateDataPtr invalid dcoIdx 0, m_dataArr.size() = 0
source\editor\FPDCODataInterface.cpp(305) : DAbort 0x00CDDDE7: FPDCODataInterface::GetOperateDataPtr invalid dcoIdx 0, m_dataArr.size() = 0
[ExecSys:0; NOT InExec]
minidump id: a956d0bb-177c-4cd2-f697-61b1d24e8a4c
</DEBUG_OUTPUT>

0x6532F1FF - nierclient <unknown> + 0
0x63524E47 - sentry <unknown> + 0
0x635249C6 - sentry <unknown> + 0
0x635253ED - sentry <unknown> + 0
0x6533540F - nierclient <unknown> + 0
0x6532EE2E - nierclient <unknown> + 0
0x6532CC7C - nierclient <unknown> + 0
0x6532A201 - nierclient <unknown> + 0
0x020CEF93 - LabVIEW <unknown> + 0
0x00E78295 - LabVIEW <unknown> + 0
0x00E75801 - LabVIEW <unknown> + 0
0x63740696 - mgcore_SH_25_3 <unknown> + 0
0x63741489 - mgcore_SH_25_3 <unknown> + 0
0x0188B3C4 - LabVIEW <unknown> + 0
0x0188BB47 - LabVIEW <unknown> + 0
0x018930AD - LabVIEW <unknown> + 0
0x01892E33 - LabVIEW <unknown> + 0
0x01892F8E - LabVIEW <unknown> + 0
0x01161CA9 - LabVIEW <unknown> + 0
0x0178C61F - LabVIEW <unknown> + 0
0x0191E090 - LabVIEW <unknown> + 0
0x00DD2F6F - LabVIEW <unknown> + 0
0x0191540F - LabVIEW <unknown> + 0
0x01E0CC20 - LabVIEW <unknown> + 0
0x017B9560 - LabVIEW <unknown> + 0
0x01DFAB7B - LabVIEW <unknown> + 0
0x017AF31D - LabVIEW <unknown> + 0
0x01A4F0D7 - LabVIEW <unknown> + 0
0x01A4D978 - LabVIEW <unknown> + 0
0x01A50536 - LabVIEW <unknown> + 0
0x017B9560 - LabVIEW <unknown> + 0
0x017B7BE7 - LabVIEW <unknown> + 0
0x017B7974 - LabVIEW <unknown> + 0
0x01A5D21D - LabVIEW <unknown> + 0
0x017B5A08 - LabVIEW <unknown> + 0
0x017B5EBC - LabVIEW <unknown> + 0

No VI call stack.

[grukfol]

Hi,

Just wanted to reply to this thread, in case it was still an issue.

I had the exact same error with the exact same code / line / LabVIEW version after trying a repair on my NI install. It was working fine before. It would only affect one of my projects, and not the others. In my case, I noticed that the error popped up while loading components of my projects, but before the error appeared, the loading window was always trying to load a class from a third party add-on that I used in this project (and not the others).

I uninstalled the add-on and re-installed it and it fixed the issue.

[cstorey]

My code always ran fine on an identical system (hardware and software), so I was unable to track down the error further.

I re-installed LabVIEW and it fixed my problem.  I suspect a virus scanner was involved in corrupting some pakage dll called by that cpp file.

Craig

[rolfk]

Actually my guess is somewhat different and related to the post just before your last one. You might have had installed at some point a Toolkit, Driver or something similar into your LabVIEW system that had a corrupted VI front panel. When LabVIEW is searching for VIs to load in its vi.ib, instr.lib, user.lib and LVAddOns folder it sometimes will run across VIs that might be damaged and that can cause such errors.

Solution: If you can find out what VIs it tries to access just prior to the crash and it belongs to a VI library that is not part of the LabVIEW standard installation, just uninstalling that library is likely enough.

Also if your VI project is linked correctly and the locations of the referenced VIs is as present on your system, LabVIEW will not have to search for VIs and would not run into this either.

Reinstalling the whole LabVIEW probably wiped the entire LabVIEW folder removing any such "rogue" VIs that might be from a driver you installed for a trial and forgot, or that you had at some point inadvertently modified and corrupted.

[PotatoEE · Accepted solution]

Uninstall SQLite Library by JDP Science resolved the issue in my case.

[dakotasmith3]

I was unable to open an entire LabVIEW project because of this same error and sometimes it wouldn't throw an error at all and just shut down LabVIEW with no messages. Uninstalling SQLite Library v1.16.0.115 from Dr JDP allowed me to open the project again. I also had LabVIEW 25Q3.

[BertMcMahan]

I recently (like 2 weeks ago) ran into an issue with that library myself- something crashed while running, and a VI got corrupted, and would hard crash LabVIEW (though with a different error code). I had to fall back to an older version from SCC. It doesn't look like the library itself was corrupted, just a VI that called it. I never did track down what specifically was the problem.

I'm wondering if a recent Windows Update/Defender change is causing an issue. That library's last new release was in 2024, so I doubt the library itself is the problem- but since it uses an external DLL, it's MUCH more likely to be able to cause crashes than a library that uses pure LabVIEW functions.