DWarnInternal 0xAFFA74F1 in LVCPUFunctions.cpp when exiting LabVIEW

[banksey255]

When exiting LabVIEW after opening a particular VI, I receive an internal warning:

DWarnInternal 0xAFFA74F1 in LVCPUFunctions.cpp

In the lvlog.txt file it states:

DWarnInternal 0xAFFA74F1: LVProcessorHierarchy: CPUs are not symmetric

Does anyone know what this means and, more importantly, how to fix it? It seems quite alarming seeing this message each time I exit LabVIEW after I working on the VI. I tried opening a previous version of my project from a time when I'm quite sure I did not experience this internal warning, but now find that the same internal warning occurs, which makes me suspect that, somehow, it isn't my code at fault, yet that is contradicted by not receiving an internal warning if I open different VIs.

If it's of any use, I've pasted in the entire contents of the lvlog.txt file below. Thanks in advance.

####
#Date: Thu, 1 Jun 2023 12:55:46 PM
#OSName: Windows 10 Enterprise
#OSVers: 10.0
#OSBuild: 19045
#AppName: LabVIEW
#Version: 19.0.1f5 64-bit
#AppKind: FDS
#AppModDate: 1/21/2021 15:54 GMT
#LabVIEW Base Address: 0x00007FF747DC0000

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 12 processors
InitExecSystem() call to GetNumProcessors() reports: 12 processors
InitExecSystem() will use: 12 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 8 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 9 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 10 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]
starting LabVIEW Execution System 2 Thread 11 , capacity: 24 at [3768432951.56669426, (12:55:51.566694260 2023:06:01)]

<DEBUG_OUTPUT>
1/06/2023 12:56:19.967 PM
DWarnInternal 0xAFFA74F1: LVProcessorHierarchy: CPUs are not symmetric
d:\builds\penguin\labview\branches\2019\dev\source\execsupp\LVCPUFunctions.cpp(33) : DWarnInternal 0xAFFA74F1: LVProcessorHierarchy: CPUs are not symmetric
minidump id: 0a2f511d-7f22-483b-83a4-59c64d17d916
$Id: //labview/branches/2019/dev/source/execsupp/LVCPUFunctions.cpp#1 $

</DEBUG_OUTPUT>
0x00007FF7481B33FC - LabVIEW <unknown> + 0
0x00007FFCA1D65389 - mgcore_SH_19_0 <unknown> + 0
0x00007FF7488E5A97 - LabVIEW <unknown> + 0
0x00007FF4D5ABF5D8 - <unknown> <unknown> + 0
0x0000017857074FE8 - <unknown> <unknown> + 0
0x00007FF7488EE410 - LabVIEW <unknown> + 0
0x0000017857070080 - <unknown> <unknown> + 0
0x0000017857D84F10 - <unknown> <unknown> + 0
0x00007FF7488EE410 - LabVIEW <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00007FF747DC0000 ***
#** Loading: "C:\Users\ban106\OneDrive - CSIRO\Documents\LabVIEW Projects\Serendipity\Main.vi"
*** End Dump ***
stopping LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 8 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 9 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 10 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
stopping LabVIEW Execution System 2 Thread 11 , capacity: 24 at [3768432991.17576313, (12:56:31.175763131 2023:06:01)]
Possible path leak, unable to purge elements of base #0

[banksey255]

I can add a little bit more testing information: On a whim, I tried disabling loop iteration parallelism on the few for loops I had enabled it for, saved the VI, then, baring the first time I exited LabVIEW after making the change, each subsequent time I exited LabVIEW after opening the VI I no longer received the internal warning, however when I re-enabled for loop parallelism, the internal warning came back.

[EthanJ]

Hi, I was wondering if you by any chance happened to dig into this error any more and find any more details about it? I ask because I'm running into the same error as you after having switched over some DVRs in my project to be EDVRs.

The reason for the switch is that I would ultimately like to wrap up part of my project into a DLL and I need to transfer large arrays of data between the DLL and the main application.

Unfortunately there aren't any easy places that I can "un-parallelize" a for loop because it's a massive project with thousands of VIs, but I will see if I can track any down that fix the crashes. But figured I'd post here asking in the meantime.

I notice from the error dump that we're both using LV 2019, maybe that has something to do with it?

####
#Date: Jul 8, 2024 2:23:55 PM
#OSName: Windows 7 Ultimate
#OSVers: 6.1
#OSBuild: 7600
#AppName: LabVIEW
#Version: 19.0.1f5 64-bit
#AppKind: FDS
#AppModDate: 1/22/2021 06:54 GMT
#LabVIEW Base Address: 0x00007FF6F8D70000

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 24 processors
InitExecSystem() call to GetNumProcessors() reports: 24 processors
InitExecSystem() will use: 24 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 8 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 9 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 10 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 11 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 12 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 13 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 14 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 15 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 16 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 17 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 18 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 19 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 20 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 21 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 22 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]
starting LabVIEW Execution System 2 Thread 23 , capacity: 36 at [3803307836.70322084, (14:23:56.703220845 2024:07:08)]

<DEBUG_OUTPUT>
2024-07-08 2:24:13.555 PM
DWarnInternal 0xAFFA74F1: LVProcessorHierarchy: CPUs are not symmetric
d:\builds\penguin\labview\branches\2019\dev\source\execsupp\LVCPUFunctions.cpp(33) : DWarnInternal 0xAFFA74F1: LVProcessorHierarchy: CPUs are not symmetric
minidump id: d8181441-ef0c-401a-8dc5-f40ac3df376b
$Id: //labview/branches/2019/dev/source/execsupp/LVCPUFunctions.cpp#1 $

</DEBUG_OUTPUT>

[banksey255]

No, my understanding of it didn't progress. I ended up just living with it as not using for loop iteration parallism was not an option, and fortunately it never actually caused a crash but rather only resulted in a warning when closing LabVIEW, which never appeared in the built application.

I have no idea why, but it eventually stopped happening on its own as I continued to develop the VI.