Mike Le Posted February 21, 2014 Report Share Posted February 21, 2014 Recently, something in our project has become corrupted such that trying to build an executable leads to a catastrophic LabVIEW crash. LabVIEW reports no errors in development mode and everything runs fine in development. We've tried a huge number of fixes with no luck. Upgrading to 2013, upgrading to the f2 patch, loading the manual fix from this thread, disabling large swaths of block diagrams, removing XControls and replacing them with classes, resetting the class hierarchies of suspected offenders, deleting the object cache, tracking down all disable structures with missing VIs and removing them, etc. We're on the verge of stepping back through our source control to find the last working build, but as it's been a long while since we last made an executable, we're likely to lose a ton of work and have to painstakingly add features back in one at a time. Trying to mass compile our code also leads to a catastrophic crash. I started mass compiling individual subfolders and removing any warnings. This is painstakingly slow and frustrating. I was finally able to mass compile one of the larger subfolders, containing a good chunk (maybe a fifth) of the total functionality. Before this, trying to mass-compile that folder would crash the LabVIEW environment. But though it didn't crash, the mass compile returned a very large list of "insane objects." It also suggested that the mass compile was terminated early by me, but I had left the machine to run over lunch and the termination was NOT user-initiated. I found this thread at NI Forums and may start playing around with removing the insane objects, but there are so many... anyone have any other suggestions? Here's the mass compile info: #### Starting Mass Compile: Fri, Feb 21, 2014 11:58:27 AM Directory: "C:RepositoryV12000LabviewDialogs"Insane object at FPHP+38C8E3D0, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.viInsane object at FPHP+222DFAC0, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctlInsane object at FPHP+CE6BC20, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctlInsane object at FPHP+41DAFE80, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.viInsane object at FPHP+41DA17B0, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.viInsane object at FPHP+423F4660, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.viInsane object at FPHP+41F704D8, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.viInsane object at FPHP+2D157018, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctlInsane object at FPHP+123797A8, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+1249DFD8, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctlInsane object at FPHP+143ED200, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+230F3680, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.viInsane object at FPHP+3E2D89C0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctlInsane object at FPHP+1C3F6E38, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+180F8BC0, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.viInsane object at FPHP+423BFE80, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctlInsane object at FPHP+34C89258, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+313BFD60, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.viInsane object at FPHP+36A83358, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+2CBD3328, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.viInsane object at FPHP+3BBF6AA0, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+39C35690, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.viInsane object at FPHP+3B73F880, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+3BEA7358, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.viInsane object at FPHP+3C811F70, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+3C815070, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.viInsane object at FPHP+3ECB3F28, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+3ECB6E50, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.viInsane object at FPHP+3EA17A40, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+3EC41E70, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.viInsane object at FPHP+4BC915D0, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.viCompileFile: skipping C:RepositoryV12000LabviewDemosConfig Dialog DemoConfig Dialog Error Demo.viInsane object at FPHP+44085928, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctlInsane object at FPHP+4E764318, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctlInsane object at FPHP+4F7FD380, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctlInsane object at FPHP+4E79A040, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctlInsane object at FPHP+4F826B48, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4F813440, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctlInsane object at FPHP+4F6F6C68, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.viInsane object at FPHP+4F712698, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.viInsane object at FPHP+4F70CD78, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.viInsane object at FPHP+4F76CD80, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.viInsane object at FPHP+4E7E26A0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctlInsane object at FPHP+4E87E4F8, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4E858388, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.viInsane object at FPHP+4E665268, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.viInsane object at FPHP+4F5458E0, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4F4F0FC0, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.viInsane object at FPHP+37923628, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+440AD550, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.viInsane object at FPHP+46057E20, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+46043AE8, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.viInsane object at FPHP+46EA4990, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+46EEC480, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.viInsane object at FPHP+4B8DECC0, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4B8B8088, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.viInsane object at FPHP+4C006C60, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4BFD3AA8, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.viInsane object at FPHP+4C2AEB48, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4C41C480, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.viInsane object at FPHP+54840EF0, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+548CC480, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.viInsane object at FPHP+4F76CD80, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.viInsane object at FPHP+4E7E26A0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctlInsane object at FPHP+4F826B48, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4F813440, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctlInsane object at FPHP+4F70CD78, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.viInsane object at FPHP+4F5458E0, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4F4F0FC0, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.viInsane object at FPHP+4F7FD380, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctlInsane object at FPHP+4E79A040, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctlInsane object at FPHP+4BDC5698, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.viInsane object at FPHP+4BDC5698, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.viInsane object at FPHP+4F712698, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.viInsane object at FPHP+4E764318, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctlInsane object at FPHP+37923628, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+440AD550, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.viInsane object at FPHP+46057E20, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+46043AE8, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.viInsane object at FPHP+46EA4990, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+46EEC480, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.viInsane object at FPHP+4B8DECC0, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4B8B8088, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.viInsane object at FPHP+4C006C60, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4BFD3AA8, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.viInsane object at FPHP+4C2AEB48, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4C41C480, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.viInsane object at FPHP+54840EF0, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+548CC480, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.viInsane object at FPHP+44085928, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctlInsane object at FPHP+4E87E4F8, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )Insane object at FPHP+4E858388, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.viInsane object at FPHP+4E665268, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.viInsane object at FPHP+4F6F6C68, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO )insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.viCompileFile: user cancelled at C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesTest Case ConfigurationTest Case Configuration.lvprojCompileFile: user cancelled at C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesTest Case Configuration SubmodulesVentilator Settings ConfigurationVentilator Settings Configuration MessagesReceive Ventilator Settings MsgDo.viMass compile terminated early#### Finished Mass Compile: Fri, Feb 21, 2014 1:44:00 PM Quote Link to comment
JackDunaway Posted February 21, 2014 Report Share Posted February 21, 2014 A few questions: Was the source code originally created in LV2013, or a previous version of LabVIEW? Do you have strictly-typed VI references that contain LVOOP objects on the connector pane anywhere in your code? Is the crash intermittent? Is the crash reproducible in all environments? (e.g., coworker's computers, other versions of LV) Are you using .NET callbacks anywhere? What additional libraries (NI and third party) do you have installed? Is dev environment in a VM or on bare metal? If you run some other CPU taxing process in parallel on the same machine (in order to deliberately steal resources from LV), does the crash still occur? Have you tried removing mutation histories from all LVClasses? If you open all offending VIs, then CTRL+A on the block diagram to select everything, then delete, then CTRL+Z to undo, does the problem still occur? Have you tried DETT in the offending context? Have you tried Procmon filtering on LabVIEW.exe events? Your issue sounds eerily similar to an issue that I'm incredibly motivated to put to rest myself, riddled with red herrings. 1 Quote Link to comment
Mike Le Posted February 21, 2014 Author Report Share Posted February 21, 2014 Hey Jack, I'll answer your questions best I can. Was the source code originally created in LV2013, or a previous version of LabVIEW?It was originally LV2012. The build problems first manifested in 2012. I upgraded my machine to 2013 to try to fix the problem, which it didn't. My coworker is continuing to try to fix the problem in 2012. It's reproducible on both our machines, though the behavior is sometimes subtly different. For example, my crash might be totally catastrophic with no error popping up. His crash might lead to a failed build and an error returning, but not an entire crash of the LabVIEW environment. If he has time, he might drop in the thread and describe what he's seeing in 2012.Do you have strictly-typed VI references that contain LVOOP objects on the connector pane anywhere in your code? I don't believe this is the case. As far as I know, we only use strict typedefs for a handful of specialized GUI cases. Other cases are standard typedefs. In none of those situations are we using an object for any of our UI effects. It's possible something to switched to a strict typedef by accident, but I don't have a good way of checking this quickly in such a large project. Is the crash intermittent?Crash happens every time I try a build. Is the crash reproducible in all environments? (e.g., coworker's computers, other versions of LV) It's happened in 2012 and 2013 so far. I think we've only tried it on our two machines. Mine is a Macbook running Windows 7 on Parallels. My coworker's computer is a PC laptop running Windows 7. Are you using .NET callbacks anywhere?I don't BELIEVE so. I'll double-check. None of the code we wrote using a .NET callback but I suppose it's possible one of the drivers or extensions we're using might. What additional libraries (NI and third party) do you have installed? JKI State Machine, JKI RSC Toolkits Palette, OpenG (all libraries included in the standard package), the Debug branch of Actor Framework, the Missing Systems Controls UI suite, Is dev environment in a VM or on bare metal?Mine is a virtual machine on a Mac; my coworker is running Windows on a PC machine. If you run some other CPU taxing process in parallel on the same machine (in order to deliberately steal resources from LV), does the crash still occur? I haven't tried it. I have a build attempt running right now, I'll give it a shot after. If I switch LabVIEW over to a single CPU in Task Manager, would that be sufficient? Have you tried removing mutation histories from all LVClasses?Not yet. I'll add that to the list of things to try.If you open all offending VIs, then CTRL+A on the block diagram to select everything, then delete, then CTRL+Z to undo, does the problem still occur? The sheer number of VIs that returned "Insane Object" errors makes me loathe to try this. I suppose I can try it with one or two VIs on the list and see if they still return an "Insane Object" error on re-compile. Have you tried DETT in the offending context?I've never run DETT during a build attempt and didn't realize that was a potential debugging option. I can add that to the list of things to try. Have you tried Procmon filtering on LabVIEW.exe events? Had to Google this. Never used Process Monitor before. Is it pretty intuitive or is there something I need to know before trying to watch the build? I'm guessing there's some logging option. Quote Link to comment
JackDunaway Posted February 21, 2014 Report Share Posted February 21, 2014 "It was originally LV2012. The build problems first manifested in 2012. I upgraded my machine to 2013 to try to fix the problem, which it didn't." << Aha. "we only use strict typedefs for a handful of specialized GUI cases. Other cases are standard typedefs" << Not strict typedefs -- do you have any strictly-typed VI references (with an LVOOP object on its conpane) statically linked to any code in your project? "The sheer number of VIs that returned "Insane Object" errors makes me loathe to try this. I suppose I can try it with one or two VIs on the list and see if they still return an "Insane Object" error on re-compile." << I feel the pain, but give it a go. If this unintuitive workaround of deleting then undoing that deletion "fixes" your root prob, we're almost certainly seeing a related issue. If the above "workaround" seems to (temporarily) fix your issue, in the context of your other answers that's enough to take this offline to compare notes, then report back here on results. One final question -- is it possible you may have refactored data structures by changing owning library of a typedef'd cluster? Quote Link to comment
Mike Le Posted February 21, 2014 Author Report Share Posted February 21, 2014 Not strict typedefs -- do you have any strictly-typed VI references (with an LVOOP object on its conpane) statically linked to any code in your project? Ah, I see. The answer is no. I feel the pain, but give it a go. If this unintuitive workaround of deleting then undoing that deletion "fixes" your root prob, we're almost certainly seeing a related issue. Right now I'm moving all the classes in and out of libraries to reset the mutation histories. If that doesn't work then I'll try the delete block diagram / undo thing next. By the way, is there a more efficient way to delete class mutation histories? One final question -- is it possible you may have refactored data structures by changing owning library of a typedef'd cluster? Well, that's definitely happened now that I'm removing mutation histories by the dropping in/out of libraries. This also happened on occasion in the past when we'd move a class (and any associated cluster typedefs) into a new library. What's the danger of that type of operation? I would imagine this happens regularly to many programmers who use both libraries and typedefs, which is a category I think most people using Actor Framework would fall into. Quote Link to comment
Mike Le Posted February 21, 2014 Author Report Share Posted February 21, 2014 I also want to note that Parallels' breaking of Ctrl+Shift+Alpha commands means I can't summon the "Object Browser" that lets you track down "Insane Objects." So that's a really fun aspect of the Parallels bug. Quote Link to comment
Neil Pate Posted February 21, 2014 Report Share Posted February 21, 2014 By the way, is there a more efficient way to delete class mutation histories? take a look at the VIs in vi.libutilityeditlvlibslvclass I believe that renaming the class also resets the mutation history. 1 Quote Link to comment
Tom Fantasia Posted February 21, 2014 Report Share Posted February 21, 2014 (edited) Hey guys, I'm Mike's state-side coworker, Tom.I have tried resetting the mutation history of every class in our depot via two methods: [*]The Set Mutation History.vi in vi.libutilityeditlvlibslvclass. [*]A custom script that deletes everything between the tags and (including the tags). After resetting the mutation history (both ways) I am able to build an executable, but the error "VI has an error of type 102208. The full development version of LabVIEW is required to fix the errors." in thrown as soon as I run the executable. Edited February 21, 2014 by Tom Fantasia Quote Link to comment
Tom Fantasia Posted February 21, 2014 Report Share Posted February 21, 2014 One final question -- is it possible you may have refactored data structures by changing owning library of a typedef'd cluster? We recently moved about 20 classes out of a library. These were mostly abstract classes, but one might have contained a typedef, but I don't think that any contain a typdef'd cluster. After resetting the mutation history for all classes as described in my previous post, a single typedef claimed to have unapplied changes. It did contain an event reference. That may be just another red herring, but I figured it worth mentioning. Quote Link to comment
JackDunaway Posted February 21, 2014 Report Share Posted February 21, 2014 Thanks for the feedback. Since you're now able to build, this could mean one of two things: your corruption is resolved, or it's dormant. (Runtime error 102208 would tend to indicate that your Run-Time Engine is not fully installed on the deployment machine you're testing the distro on -- my hunch is this might be unrelated altogether to the original issue) Errors/corruptions like this are nearly always solvable within a single targeted debug session, with some combination of mass compile, clear object cache, clear mutation histories, inspect linker info for anomalies, procmon or DETT, clues from the crashdump, or at least narrow down to single simple repro and ask for the CAR and refactor to avoid that issue. Inconvenient, but certainly no big deal or more than a half hour. This particular corruption issue (on my side, at least) has had me baffled for over a month, and has manifested itself as several disjoint bad behaviors on end-user's machines, and intermittently. Sometimes, the application runs for weeks, then one day crashes to desktop every time the application is launched. Sometimes, it crashes the first time, but works repeatably each session thereafter for the day. Sometimes, it's crash to desktop, sometimes it's a silent no-op, where a function just doesn't execute. The worst part -- every time I try a new solution, and it appears to be the right solution, but it'll eventually pop up again, but only for a select few customers. Whack a mole with red herrings -- that's been my MO for some time now, which is why I'm eagerly following this thread. Quote Link to comment
Mike Le Posted February 23, 2014 Author Report Share Posted February 23, 2014 (edited) Tom was able to track the problem down by painstakingly going through our source control and finding the point at which builds no longer worked. It turns out that it CAN be traced back to when we pulled the 20 abstract classes out of their library. We have no idea why this caused such an obscure and massively catastrophic set of errors from LabVIEW. Can anyone provide any insight on that? In the past, I've experienced some baffling and frustrating problems when pulling classes in or out of libraries. Nothing to this extent, but I'm wary of this operation (even moreso now!). Can anyone provide any insight as to why LabVIEW is so bad at handling what should be a simple organizational action? Additionally, is there any way to fix this without having to revert all our source code back to that point and "start over" with all our feature additions? It's over 2 weeks' of coding that we'd basically have to reimplement. Edited February 23, 2014 by Mike Le 1 Quote Link to comment
Tom Fantasia Posted February 23, 2014 Report Share Posted February 23, 2014 Just to (kind of) close the loop on this problem. I'll summarize what we found. A couple of weeks ago I removed about 20 (mostly abstract) classes from a library. I did this by: Adding all of our source code to a new project (in order to load everything into memory). Right clicking on the classes in question and selecting "remove from library" Our main VI continued to work afterwards, but the EXE started throwing a 1502 error. Changing the "Additional Exclusions" settings as described in this thread didn't help any: http://forums.ni.com/t5/LabVIEW/Error-while-creatiing-executable-Error-1502/td-p/669757 Anyone have any idea why removing classes from a library would cause the EXE, but not the VI to break? 1 Quote Link to comment
JackDunaway Posted February 24, 2014 Report Share Posted February 24, 2014 Additionally, is there any way to fix this without having to revert all our source code back to that point and "start over" with all our feature additions? It's over 2 weeks' of coding that we'd basically have to reimplement. Here's what I would try -- this process anecdotally has helped me, and could help you as well: Ensure repo is up to date with all latest developments; ensure that you have no outstanding changesets or modifications to the working copy, and your team working in parallel has no outstanding modifications that could cause a conflict in SCC Open project From root node in project, right-click to "Properties >> Project page >> Mark Existing Items button >> ensure every item from dialogue is 'marked'" Save all Restart LabVIEW From GSW, Clear Compile Object Cache Restart LabVIEW These sub-steps are performed as one "transaction" within the context of one IDE session: Open project Recreate that parent library with the exact same name with your up-to-date repo Drag all your ~20 classes back into the library (i.e., the way it used to be) Mass compile (and perhaps, see lots of "problems") Mass compile once more (and probably, most/all "problems" go away) Drag all 20 classes back outside the library (i.e., the way you want it to be) Mass compile (and perhaps, see lots of "problems") Mass compile once more (and probably, most/all "problems" go away) Restart LabVIEW [*]From GSW, clear compiled object cache [*]Restart LabVIEW [*]Open project -- build the EXE -- hopefully, the problem is gone. If so, commit to SCC, with a comment why you just modified 100's or 1000's of VIs Quote Link to comment
ShaunR Posted February 24, 2014 Report Share Posted February 24, 2014 Here's what I would try -- this process anecdotally has helped me, and could help you as well: Ensure repo is up to date with all latest developments; ensure that you have no outstanding changesets or modifications to the working copy, and your team working in parallel has no outstanding modifications that could cause a conflict in SCC Open project From root node in project, right-click to "Properties >> Project page >> Mark Existing Items button >> ensure every item from dialogue is 'marked'" Save all Restart LabVIEW From GSW, Clear Compile Object Cache Restart LabVIEW These sub-steps are performed as one "transaction" within the context of one IDE session: Open project Recreate that parent library with the exact same name with your up-to-date repo Drag all your ~20 classes back into the library (i.e., the way it used to be) Mass compile (and perhaps, see lots of "problems") Mass compile once more (and probably, most/all "problems" go away) Drag all 20 classes back outside the library (i.e., the way you want it to be) Mass compile (and perhaps, see lots of "problems") Mass compile once more (and probably, most/all "problems" go away) Restart LabVIEW [*]From GSW, clear compiled object cache [*]Restart LabVIEW [*]Open project -- build the EXE -- hopefully, the problem is gone. If so, commit to SCC, with a comment why you just modified 100's or 1000's of VIs We need a W.T.F smiley! 2 Quote Link to comment
Tim_S Posted February 24, 2014 Report Share Posted February 24, 2014 Here's what I would try -- this process anecdotally has helped me, and could help you as well:[snip] At what point do you do the hokey-pokey? Quote Link to comment
Tom Fantasia Posted February 25, 2014 Report Share Posted February 25, 2014 Here's what I would try -- this process anecdotally has helped me, and could help you as well: Ensure repo is up to date with all latest developments; ensure that you have no outstanding changesets or modifications to the working copy, and your team working in parallel has no outstanding modifications that could cause a conflict in SCC Open project From root node in project, right-click to "Properties >> Project page >> Mark Existing Items button >> ensure every item from dialogue is 'marked'" Save all Restart LabVIEW From GSW, Clear Compile Object Cache Restart LabVIEW These sub-steps are performed as one "transaction" within the context of one IDE session: Open project Recreate that parent library with the exact same name with your up-to-date repo Drag all your ~20 classes back into the library (i.e., the way it used to be) Mass compile (and perhaps, see lots of "problems") Mass compile once more (and probably, most/all "problems" go away) Drag all 20 classes back outside the library (i.e., the way you want it to be) Mass compile (and perhaps, see lots of "problems") Mass compile once more (and probably, most/all "problems" go away) Restart LabVIEW [*]From GSW, clear compiled object cache [*]Restart LabVIEW [*]Open project -- build the EXE -- hopefully, the problem is gone. If so, commit to SCC, with a comment why you just modified 100's or 1000's of VIs Thanks for the detailed response Jack. I was able to get to step 8.3 before labview hung up on me for 2 hours. Quote Link to comment
JackDunaway Posted February 25, 2014 Report Share Posted February 25, 2014 Thanks for the detailed response Jack. I was able to get to step 8.3 before labview hung up on me for 2 hours. :-( Perhaps try again, except this time, one at a time, rather than all 20 at once? Else, are you still having problems, or does it seem to be working again? Quote Link to comment
Tom Fantasia Posted February 26, 2014 Report Share Posted February 26, 2014 Thanks for your help Jack. We ended up going back to a known working version of the code base. That seemed like the fastest way to get the code working again. Quote Link to comment
Mike Le Posted February 27, 2014 Author Report Share Posted February 27, 2014 "Fastest" being a relative term, but a couple weeks recoding is apparently faster than getting LabVIEW to resolve what should be a totally elementary organizational operation. This would be one of the "troughs" in our love/hate relationship with LabVIEW. Quote Link to comment
Neil Pate Posted February 28, 2014 Report Share Posted February 28, 2014 "Fastest" being a relative term, but a couple weeks recoding is apparently faster than getting LabVIEW to resolve what should be a totally elementary organizational operation. This would be one of the "troughs" in our love/hate relationship with LabVIEW. I feel your pain Mike, This advice will probably come across as totally patronising (it really is not meant to be), but I really recommend nightly builds of all executables, committed into your VCS. Doing this generally saves a whole bunch of time when LabVIEW throws its toys out the cot. Quote Link to comment
Mike Le Posted March 1, 2014 Author Report Share Posted March 1, 2014 That's actually a great suggestion, neil. I'll pitch it to the team and see what they think. Considering the frustration we're going through, this is as good a time as any to implement some proactive/preventative measures. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.