Error 1097 labview - Исправление ошибок и поиск оптимальных решений проблем

Reported In

Reported In shows products that are verified to work for the solution described in this article. This solution might also apply to other similar products or applications.

Operating System

Windows
PharLap

Issue Details

My LabVIEW code references an external DLL. When I run my program, I get a message that says Error 1097 occurred at the Call Library Function node, but my program does not stop execution.
How can I troubleshoot error 1097 in LabVIEW?
What causes error 1097 to occur at the Call Library Function Node?

Error 1097: LabVIEW (Hex 0x449): An exception occurred within the external code called by a Call Library Function Node. The exception might have corrupted the LabVIEW memory. Save any work to a new location and restart LabVIEW.

Solution

LabVIEW error 1097 often occurs due to an exception being passed inside the DLL that LabVIEW is unable to process. There are two main causes of this:
1. The Call Library Function Node parameter datatypes are incorrectly configured.
2. Memory is being incorrectly handled by your program.

Troubleshooting steps:

Ensure that the DLL works properly outside of LabVIEW, and that the Call Library Function Node parameter datatypes are configured to match the datatypes expected by the DLL function.
The DLL may be designed specifically for 32-bit (or 64-bit) applications. Calling it on LabVIEW 32-bit (or 64-bit) may resolve the error.
Error 1097 may also indicate that memory is being handled improperly by your program due to improper calling convention in your Call Library Function Node.
The stdcall (WINAPI) convention expects that the DLL will handle memory usage, while the C calling convention expects that LabVIEW will handle memory usage. Using the stdcall (WINAPI) convention improperly can result in un-handled memory. The calling convention can be configured by double-clicking your node and changing the selection, as shown in the image below.

Was this information helpful?

Источник

Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

Search instead for

Did you mean:

Topic Options

Subscribe to RSS Feed
Mark Topic as New
Mark Topic as Read
Float this Topic for Current User
Bookmark
Subscribe
Mute
Printer Friendly Page

All Forum Topics
Previous Topic
Next Topic

Previous
- 1
- 2
- 3
Next

Hi,

I am getting error code 1097 in DLL calling function. Please find the DLL calling function details for more information.

Function : GetControllerListTest(controller *ptrControllertest,char *max_controller);

Controllertest parameter details:

define NO_OF_CONTROLLER  100
#ifndef CONTROLLER_STRUCT
typedef struct
{
  CString name;
  char status;
  CString blocked_by;
  char group;
}controller;

Controllertest parameter data type is structure. In LabVIEW, I have configured parameter as a cluster.

name : String control

status : U8 Integer control

blocked_by : String control

group : U8 Integer control

Could you please confirm it, did I configured the datatype in correct way?

I am getting empty array output and Error Code from the DLL 1097. Can you please tell me where I am missing?

Thanks

Sivaramkumar.V

The error you mentioned says:

An exception occurred within the external code called by a Call Library Function Node. The exception might have corrupted the LabVIEW memory. Save any work to a new location and restart LabVIEW.

If you are using LabVIEW version above 9.0, I recommend you to cross check the calling convention for your dll. It must be defined as»C» and not as WinAPI.

Second thing, you would also need to check your text based code by passing the same parameters you did in LabVIEW

-FraggerFox!
Certified LabVIEW Architect, Certified TestStand Developer
«What you think today is what you live tomorrow»

nathand

How is the type «CString» defined?

If it’s a C++ type, as defined here, then you cannot call this function directly from LabVIEW because LabVIEW cannot pass C++ types. In this case you’ll need to write a wrapper (in VisualStudio or another C++ programming environment) that takes a standard C string (character array) as an input, creates a CString from it, and calls GetControllerListTest.

If CString is defined as a fixed-length character array, then you need to replace the LabVIEW strings with clusters of U8 containing a number of elements equal to the string length (LabVIEW does not support fixed-length arrays).

If CString is defined as a pointer to an array of characters, you can pass the data to it from LabVIEW, but you need to call LabVIEW memory manager functions to allocate memory for the string and copy data into it.

Author

Hi, Thanks For the Information. I have created the wrapper layer in dll…successfully done…

Sir i am too facing the 1097 error and idont know how to create the wrapper. so please can you help me?

also if you can send me the wrapper code it would be a kind help for me.

Hi Fragger Fox. I am getting the 1097 error after moving from LabVIEW 8.6 to LabVIEW 2010 when calling a third party dll that worked fine under LabVIEW 8.6. What I wanted to mention though is that I tried changing the clf node from Win API to C. Now when I call the clf node, LabVIEW (I’m on 2010 now) crashes. When I switch back to Win API, I again get the 1097 error but LabVIEW does not crash. I also tried changing from Win API to C in some of my other VI’s that contain clf nodes that call into the Windows API (kernel32.dll, user32.dll, etc.) and that was causing LabVIEW to crash as well. When I set those back to Win API, those calls into the Windows API work fine (like they did under LabVIEW 8.6) — no error and no crash. Just wanted to mention this, because it does not seem that your tip to use «C» instead of «Win API» in clf nodes works for me on LabVIEW 2010 (which is version 10.0 and is therefore above 9.0).

Thanks,

rolfk

Call Library Node problems without the VI in question attached AND the complete C prototype of the function provided, AND preferably some documentation about the C function in question can be not diagnosed. These informations are paramount to get the Call Library Node configured properly since there is no way a calling application can retrieve the necessary information from the DLL itself. The DLL interface was never intended to be a self configuring interface and it was designed with the understanding, that the user of such an interface is a fully knowledgeable C programmer knowing both, how to read a header file definition as well as various details about memory buffer handling.

So show us your VI and the C header file, and we can start to help you. Otherwise all we can do is guessing in the way you have done with changing the calling convention randomly. You can of course try to shoot in the shooting range with a blindfold on, but the chances that you not only do not hit the target, but injure some other person instead is very high.

The only reason that the suggestion from Fragger Fox has any merits is the fact that LabVIEW used to have some heuristics that changed the Call Library Node automatically from C calling convention (the LabVIEW default) to Windows calling convention, if it recognized a certain pattern in the exported function name. This heuristic was removed in LabVIEW 2009 because it did prevent the Call Library Node to be able to call functions that were using C calling convention but happened to match the heuristic pattern. So changing a Windows calling convention to C calling convention when the code has «seemed» to work before is NEVER a solution.

Hi Billy,

Post your C header file and the VI if its possible. Switching between calling conventions is not a solution. I mentioned it just to make the poster aware of this while switching between LV versions.

There are many reasons for this error, and we can’t judge anything without having a look at the code structure. The error itself says that «An exception occurred within the external code called by a Call Library Function Node.», so we need to check the dll code first.

-FraggerFox!
Certified LabVIEW Architect, Certified TestStand Developer
«What you think today is what you live tomorrow»

rolfk, respectfully. The point of my last post (addressed to FraggerFox and not you by the way) was really just an FYI about LabVIEW 2010 crashing after changing from «WINAPI» to «C» calling convention in a clf node. I was seeing this behavior in these cases.

1) A VI making a call into a DLL (via clf node) that was previously giving the 1097 error.

2) A VI making a call into a DLL (via clf node) that was previously working (no 1097 error or any error). This case is observed with many such previously working VI’s that I have been using regularly and that call into a DLL via a clf node no matter what the dll (kernel32.dll, user32.dll, or third party).

So the point was really the crash and not the 1097 error. I did not include an example VI because, as I mentioned, I intended the post as just an FYI to FraggerFox about the crash and did not intend for anyone to try and debug any particular instance of my observing said crash. I figured if FraggerFox wanted more information, he would ask for it. And he has done so — in a respectful and professional manner.

Feel free to reply to my posts even if they are not directed to you, but please be respectful and professional. Being a LabVIEW Champion does not give you license to be snide.

Previous
- 1
- 2
- 3
Next

All Forum Topics
Previous Topic
Next Topic

Источник

Hi @Tonym,

I loaded up the LabForms VI on LabVIEW 2014 and was in general able to successfully run it as advertised from the Instructable I linked before, and I was able to adjust the timebase on the Waveform Generator, but it does have it’s own set of caveats. What I ended up doing was going to the block diagram and double clicking on the two Simulate Signal Express VI’s that are towards the bottom middle of the block diagram. There you can change the Samples per second and the Number of Samples (will currently have the automatic box ticked and be set at 100000); with the default configuration of 250 MHz and 100000 samples, this leads to a total time of 0.0004 seconds, which is what you see on the WaveGen graph.

You can untick the automatic box and increase the samples, but you will likely be encountered with an error that says the system may not perform as you expect; be sure to the click the «Use Anyway» button rather than the reconfigure. When I first clicked reconfigure, an error kept popping up saying the system couldn’t run (or something similar) every time I closed the error, effectively softlocking me out of LabVIEW and forcing me to use the task manager to shut down LabVIEW. The «use-anyway» option let me run the VI and did work as expected, but as I was warned by LabVIEW, the system definitely did slow down when the VI was running. You can slow down the sample rate from 250 MHz, though I don’t know how much that will impact your intended application (especially at higher frequencies). So not an AD2 problem per se, but more of a limitation with what sort of configurations have been implemented into the VI’s (since the VI’s just call existing WaveForms SDK functions).

Thanks,
JColvin

Источник

Recommended Posts

0_o

Newbie

- Report
- Share

Hi,

My LabVIEW 2016 32 bit is crashing a lot.

I can guess it is related to:

1. incompatibility with DAQmx 9.1.5 and the related device driver which I need for LabVIEW 8.5.1 which I also use (NI’s support jumped on that issue yet I think it is not related)

2. an addon that I use to access OpenCV leaving some references open in the dlls

3. Controls with same label or with no label (I believe that this is the issue —LV can’t recover correctly in such cases)

However, I don’t want to guess like NI’s support that it is point 1 and do nothing to prove it.

I expect to see the reason in a log file yet the support wasn’t able to show me where to find it.

Searching around I found the dmp file under documentsLabVIEWdata

Is that the way to check those crashes or one of you know of a better way to check it beside elimination?

Thanks in advance

Quote

Link to comment

- Report
- Share

Opinions of Applications Engineer and not of NI R&D

Each crash is going to create a .zip with an lvlog.txt and multiple .dmp files. The lvlog.txt will first print some basic information about your setup; OS Build, AppName (LabVIEW if it’s the dev environment), LV Version, etc. The log will then print out some thread information which has never been all that informative to me. Finally you will see a Debug Output section for each DWarn or DAbort. A DWarn is something that LV could recover from and a DAbort is something that LV could not recover from. Usually the DAbort is what we are concerned with but if we get 20+ DWarns printed quickly before a crash I typically suspect they are pretty related to the crash. I looked at a log on my computer and found the following.

<DEBUG_OUTPUT>
2/27/2018 8:21:52.351 AM
DWarnInternal 0xB0BC654A: No path given for current component in JSON map file. C:ProgramDataNational InstrumentsLVComponentLocationInfoLVToolsProductMap.json
e:buildspenguinlabviewbranches2017devsourcepanelshowerr.cpp(3732) : DWarnInternal 0xB0BC654A: No path given for current component in JSON map file. C:ProgramDataNational InstrumentsLVComponentLocationInfoLVToolsProductMap.json
minidump id: 9c36ea77-c0f5-45bb-8b2f-2c4267d223ca
$Id: //labview/branches/2017/dev/source/panel/showerr.cpp#5 $

The first line is the time of the error. The next two lines print the actual error message (if it has one) and the source where that error happened. Finally it prints the minidump id which ties this particular error back to a specific .dmp file in the zip folder. If you open the dump file of a minidump and have the correct symbols loaded you will be able to see the call stack but not much else (unless you have enabled full dumps). How much help you get from looking at this information is going to vary greatly depending on the particular crash but the most I personally hope for is a good indication of where to start looking. For instance, if the entirety of the call stack is DAQmx calls, looking at the DAQmx portion of your application sounds like a good place to start at least. Now the stack may just show that LV is allocating/copying memory and then messing with the Data Space. If that’s the case, then we have to look for when LV may be allocating memory which means we haven’t really learned anything too useful.

Now let’s say that we actually get useful information out of this and I can tell you that the reason for the crash is that you are trying to read data from a NULL channel reference (I’m just making that up). Now we’ve found the root cause in our source but we’re not really closer to actually resolving your crash are we? The crash logs may tell us what went wrong at the lowest level in the LabVIEW source but without knowing how we ever got into that situation we aren’t really able to make any recommendations for you to act upon. This is why having a reproducing test case is so important. If we know what went wrong and can show how we got there, we can take it to the appropriate people.

TLDR: If you do attach some crash logs I am willing to take a quick look and let you know what I see but I can’t promise anything.

Link to comment

0_o

Newbie

Author

- Report
- Share

Thank you for the reply.

If it was code related I could have sent you a code sample.

However, it feels more like an environment issue to me.

If I save everything there will be no crash. If I code for a couple of hours without saving… a crash will be very likely no matter what project I’m working on.

It can even be related to a strong antivirus access blocking issue. I don’t want to guess, do an endless elimination or reinstall LV. I want proof.

The direction you give is what I found. Thanks for the analysis example. I wish NI gave a tool that would analyze that dmp file for us.

Attached you can find the dmps and the MAX report in case you can understand the reason for the crashes.

How do I load the correct symbols in order to understand that dmp file? You din’t give an example to that part

16.0f5 (32-bit).zip

ni_support.zip

That said, I would love to understand what NI R&D would do? How do I turn on full dump reports?

Are there other tricks that could help me find the culprit?

How does other programmers here handle such issues?

Edited March 28, 2018 by 0_o

Quote

Link to comment

LogMAN

- Report
- Share

Some of your crash logs point towards the TSVN Toolkit. Possibly related: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019RInSAM

Edit: OpenCV also causes some issues:

<DEBUG_OUTPUT>
21/02/2018 17:31:12.240
DWarn 0x50CBD7C1: Got corruption with error 1097 calling library OpenCVWrapperToCpp.dll function ?lv_Canny@@YAXHHNNH_NPAH@Z

I suppose you were working with the Call Library function at that moment, so these problems are to be expected. Just make sure to restart LV every now and then to reset the memory or LV will crash eventually.

Edited March 28, 2018 by LogMAN

Link to comment

0_o

Newbie

Author

- Report
- Share

LogMAN, you are correct. Thanks!

I wonder why NI’s support eng that connected to my computer couldn’t tell me the same? He simply searched for an incompatibility issue that could save him from dealing with the problem.

I too saw those issues:

1. providers always race with the internal provider and cause problems.

2.OpenCV DLL wrapper… DLL…

However, the crashes didn’t happen during execution and you refer to DWarns and not DAborts.

Thus, I think more in the line of memory issues from call libraries.

Can you elaborate as to the reason it happens.

I have several ways to check for memory issues and already saw that even when I close a reference to a dll using the call library the memory is not freed till the calling vi is closed (BD closed) and that is often the stage when LV crashes.

Analyzing a video and keeping the snapshots in an array can get LV from 50MB RAM to 380 MB in no time and this is a 32bit version (2GB max RAM). From my experience the issue is FP memory usage. Even 50MB under 1 control is an issue.

Why should the call library behavior be expected? Anyway to prevent it without restarting once a hour? The exe should work 24/7. I can’t ask for it to be restarted for memory issues every couple of hours.

Thanks in advance.

Edited March 28, 2018 by 0_o

Quote

Link to comment

LogMAN

- Report
- Share

40 minutes ago, 0_o said:

However, the crashes didn’t happen during execution and you refer to DWarns and not DAborts.

You mean they didn’t happen in the executable right? The executable has no automatic error handling (unless compiled with debugging enabled, maybe), so the errors still happen but silently.

Error 1097 indicates that the library corrupted memory. Memory that doesn’t belong to the library, which is a serious issue. I’m not an expert with Call Library nodes, but this should be taken care of. Here is an article that might be of help: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6tcSAC

@jacobson mentioned before:

19 hours ago, jacobson said:

A DWarn is something that LV could recover from and a DAbort is something that LV could not recover from.

A DWarn doesn’t mean LV restored the corrupted memory, just that it was able to continue operation despite the memory being corrupted. You should still make sure it doesn’t happen again!

42 minutes ago, 0_o said:

I have several ways to check for memory issues and already saw that even when I close a reference to a dll using the call library the memory is not freed till the calling vi is closed (BD closed) and that is often the stage when LV crashes.

Sounds to me like the Call Library nodes are not configured properly. The library is unloaded by LV when closing a VI which causes the library to free all of its memory. Since the library accessed memory in the address space of LV, it tries to free it, causing LV to crash in the process.

44 minutes ago, 0_o said:

Why should the call library behavior be expected?

I meant that this is to be expected while working on the Call Library node. At least it takes me a while to figure out the correct settings before it works without errors.

Quote

Link to comment

0_o

Newbie

Author

- Report
- Share

I meant execution in that paragraph. Not executable. In later paragraph I meant the executable.

4 minutes ago, LogMAN said:

Sounds to me like the Call Library nodes are not configured properly. The library is unloaded by LV when closing a VI which causes the library to free all of its memory. Since the library accessed memory in the address space of LV, it tries to free it, causing LV to crash in the process.

This line you wrote is the solution in my case I guess.

I’ll update the person who created that code and hope for a quick fix.

Thank!

Quote

Link to comment

- Report
- Share

In your case, regardless of how many DWarns are thrown, the actual DAbort seems pretty much the same every time. Basically, there are a bunch of general LabVIEW calls, a few mxLvProvider calls and a single msvcr call that seem the same between every crash, and then we go straight into crash reporting calls. I believe the mxLvProvider is the LabVIEW project provider (maybe @David_L remembers some of this?) and if that is the case my best guess would be problems with the TSVN toolkit as LogMAN suggested (not only because of the DWarns but because I believe TSVN does some project provider things).

As for one of your earlier questions, you won’t have the correct symbols unless you work for NI. One thing I do like quite a bit about LabVIEW NXG is that the call stack with full function names is printed in the log so that’s something to look forward to.

Quote

Link to comment

David_L

Newbie

- Report
- Share

mxLvProvider definitely refers to some project provider code, and TSVN is almost completely a project provider add-on. The best bet in this case would be to uninstall TSVN and see if you still see crashing. If the problem points to TSVN you might be able to reach out to the developer, but since it’s a free toolkit I don’t know how much bandwidth they put into development and updates on it.

Link to comment

JKSH

- Report
- Share

16 hours ago, 0_o said:

However, the crashes didn’t happen during execution and you refer to DWarns and not DAborts.

Thus, I think more in the line of memory issues from call libraries.

Can you elaborate as to the reason it happens.

… the memory is not freed till the calling vi is closed (BD closed) and that is often the stage when LV crashes.

That is the nature of memory corruption: Often, it doesn’t cause a crash immediately. The crash happens later, when something else tries to use the corrupted memory.

16 hours ago, 0_o said:

Analyzing a video and keeping the snapshots in an array can get LV from 50MB RAM to 380 MB in no time and this is a 32bit version (2GB max RAM). From my experience the issue is FP memory usage. Even 50MB under 1 control is an issue.

This is monitoring memory allocation. It helps you detect memory leaks, but doesn’t detect memory corruption. They are different issues.

Memory leaks cause crashes by using up all of your application’s memory. Memory corruptions cause crashes by scrambling your application data.

Quote

Link to comment

- Report
- Share

Error 1097 is hardly related to a resource not being deallocated but almost always to some sort of memory corruption due to overwritten memory. LabVIEW sets up an exception handler around Call Library Nodes if you don’t disable that in the Call Library Node configuration, that catches low level OS exception, and when you put the debug level to the highest, it also creates some sort of trampoline around buffers. That are memory areas before and after buffers passed to the DLL function as parameter and filled with a specific pattern and after the function returns to LabVIEW, it checks that these trampoline areas still contain the original pattern. If they don»t then the DLL call somehow wrote beyond (or before) the buffer it is supposed to write too and that is then reported as error 1097 too. It may only affect the trampoline area and that would mean that nothing really bad happened, but if it overwrote the trampoline areas it may just as well have overwritten more and then crashes are going to be happening for sure, rather sooner than later.

In most cases the reason for error 1097 is actually a buffer passed to the function that the function is supposed to write some information into. Unlike in normal LabVIEW code where the LabVIEW nodes will allocate whatever buffer is needed to return an array of values for instance, this is not how C calls usually work. Here the caller has to preallocate a buffer large enough for the function to return information in. One byte to little and the function will overwrite some memory it is not supposed to do.

I’m not sure which OpenCV wrapper library you are using, but image acquisition interfaces are notorious to make such buffer allocation errors. Here you have relatively large buffers that need to be preallocated, and the size of that buffer depends on various things such as width, height, line padding, bit depth, color coding etc. and it is terribly easy to go wrong there and calculate a buffer size to allocate that will not match with what the C function tries to fill in because of a mismatch of one or more of these parameters.

For instance if you create an IMAQ image and then retrieve its pointer to pass to the OpenCV library to copy data into, it will be very important to use the same image type and size as the OpenCV library does want to fill in, and to tell OpenCV about the IMAQ constraints such as the border size, line stride, etc.

Edited April 1, 2018 by rolfk

Quote

Link to comment

0_o

Newbie

Author

- Report
- Share

Removed TSVN and still got the crash.

Sometime before the crash I got the following runtime error directing to the culprit.

Thanks! I love this community

Quote

Link to comment

Join the conversation

You can post now and register later.

If you have an account, sign in now to post with your account.

Источник

Home

The Global Leader in DDS. Your Systems working as one.

Search

error 1097 in test_suite and zipped-dataset.vi

Created:

2017-09-18

Updated:

2017-10-05

Hi Martijn, first of all thank you for your effort in developing this great library!

I have now picked up the latest h5labview2 version for a new project I’m working on, and I get a 1097 error in various places:

in the zipped-dataset.vi, in the H5Dclose.vi. However, the output h5 file seems to be generated correcty, at least judging from HDFView and the h5stat command line utility.

in the test_suite.vi, both array_timestamp and timestamp fail with the same error which is generated already in the H5Dwrite

I’m using HDF5 v1.8.19, but the same error occurs with 1.8.14. I have already tried installing and re-installing HDF and h5labvew, and also the Visuall C++ Redistributables (2010 and 2015 x86).

By the way, I’m on LabVIEW 2016 x32, on Windows 10×64.

Can you give me any advice on where I could look to solve the problem? If needed, I can send you LabVIEW log and dump files, or the generated h5 file.

Thanks again!

Carlo
Last edit: Carlo Dri 2017-09-18

ok, I have just tried using the latest h5labview2 snapshot. The test_suite.vi errors are now solved, but the zipped-dataset.vi 1097 error is still there…

Any help would be greatly appreciated…

Hi, thanks for the bug report. Can you send me the crash report for zipped-dataset.vi? Does the VI crash if the offending call is removed or does it occur when the VI concludes?

I’ve attached a debug build of the DLL for 32-bit LabVIEW. Please replace the one in <vi.lib>/addons/h5labview2/lib and run zipped-dataset.vi. It will generate a file %TEMP%/h5labview.log; please attach it so I can check what’s causing the error to occur.

Cheers,
Martijn

Thanks Martijn. You can find attached a zip file containing:

the zip file of the LV crash report

the .log file generated with your debug dll

and I also added:

the .h5 file produced when the error occurs

the .h5 file that is succesfully produced (no errors) when only the deflate filter is used

the .h5 file that is succesfully produced (no errors) when only the scale-offset filter is used

In fact, I did some more testing and it seems like the error is triggered only when using together the scale-offset and the deflate filter, but the VI finishes succesfully when I remove one of the two filter.

By the way, on a second look, the .h5 file generated when the error occurs is not ok: the reported storage size is zero, and it contains only zeros.

thanks again for your help,

Carlo
Last edit: Carlo Dri 2017-09-18

same behavior with HDF5 v1.8.18:test_suite passing, but zipped_dataset fails with error 1097.

ok, I just tried on my colleague’s PC which is almost identical to mine (both hardware and software-wise), and everything works fine, also with v1.8.19. Therefore, it seems like a problem confined to my system, and I’m running out of hypotheses…

I am suspecting a corrupt LabVIEW installation, but it’s a long shot…

If you have any info from the logs, please drop me a line, thanks!

Thanks for coming in Dan! Well, I think I have the necessary VS Runtimes already installed: for 1.8.19 I’m using the latest vc2015, but I have also tried 1.8.18 with vs2012 and 1.8.14 with vs2010. Now I have tried to reinstall the vcs, but still no luck.

I have to say that I have quite a mess concerning VC Redistributables on my system (see attached screenshot). I don’t know if this is a problem but I have no idea how to manage all these versions.

Microsoft’s failure to manage runtimes is a well-known problem — basically the only way for developers to guarantee compatibility is to ship their specific version of the runtime with every product. Runtime compatibility is really bad between versions, and it’s normal to have MANY installed side-by-side (giving rise to the «MANIFEST» system and its own problems).

I compiled h5labview with VS2012, which means for best compatibility you want HDF5 using VS2012, and to put the dependent DLL (msvcr110.dll) in the «lib» directory. Even if you have all the DLLs installed, the rules for which one gets loaded at a given point in time are convoluted.

To ensure the correct files are loaded, try copying hdf5.dll, szip.dll and zlib.dll from the «bin» folder of the HDF5 install directory to the «resource» folder of the LabVIEW install directory. If there are other versions in your PATH variable that would explain why specifically your computer has an issue, not your colleague’s.

However, if this were a problem, it would be more likely that the library wouldn’t work at all, instead of failing on a specific combination of calls. DLL incompatibility seems most probable though.

Cheers,
Martijn

Hi Martijn,
thanks for your detailed feedback. I have tried to copy the relevant files (both HDF-related and MSVCR) in the proper folders as you suggested, also ensuring that no other copies of the libraries are available in the PATH variable (e.g. using the «where» command). Sadly, none of my attempts worked, the error is always the same.

In a moment of despair, I also repaired my entire LabVIEW installation, but again, no luck.

If you have any other suggestions (other than reformatting my whole system), they are very welcome.

Carlo

Carlo,

I don’t mean to hijack your thread, but I have a question about your second post: could you explain what you did to get rid of the 1097 errors in the test suite? What do you mean with «the latest h5labview2 snapshot»?

I’m having the same 1097 errors in the test_suite on the timestamp and array_timestamp tests. I’m using LabVIEW 2016 (32 bit) on Win10 (64 bit), with hdf5-1.8.19-Std-win7_32-vs2013.zip and h5labview2-2.13.1.143.vip.

Is there a newer snapshot than h5labview2-2.13.1.143.vip? If so, I’m not finding it.

Best regards,

Victor

Hi Victor! No problem, glad to help. I’m referring to the latest development snapshot that you can get from the code repository. Just click «Code» in the above navbar and then «Download Snapshot». Then you can follow the manual installation instructions here.

By the way: does the «zipped-dataset» example run fine on your system? Just hoping to find some answers to my issue!

Thanks Carlo for clarifying that. I get green dots across the board now.

Hi Martijn,
I have a smal update on this topic. I reformatted my entire system, and after installing labview and h5labview everything worked fine, especially with the zipped-dataset (with hdf5-1.8.19-Std-win7_32-vs2013). After that, I installed Foxit Reader Free and SolidWorks 2017 SP4.1 and the usual 1097 error popped out again. So there must be something in these two apps are installing that messes things up with h5labview. Did you manage to get something out form the logs I sent you? Can I provide you with any other log or info to trace the problem?

Thanks again…

Carlo

Ok, I FINALLY nailed the problem down. Using Sysinternals Process Monitor I was able to capture which dlls (from which folders) are exactly loaded by h5labview while running the zipped-dataset.vi.

In my first capture, while the 1097 error occurred, you can see the loaded dlls in the Capture.PNG attachment. So I said ok, I can see what might cause trouble here: both szip.dll and zlib.dll are loaded from SysWOW64 folder, not from the HDF5 bin folder.

Then I copied all three hdf5.dll, szip.dll and zlib.dll to the LabVIEW resources folder and I was expecting all three dlls to get loaded from there. And I did another capture to check if the file load path had changed. And no, it didn’t (see Capture2.PNG), the files still get loaded from the SysWOW64 folder (is this a bug?) and the 1097 error was in fact there.

Then I renamed the zlib.dll in the SysWOW64 folder to no-zlib.dll and the zipped-dataset.vi worked flawlessly!

Martijn does this point you to something that could be wrong in the h5labview code? Why don’t the dlls get loaded from the LabVIEW resources folder?

Hi Carlo,
Congrats on finding the problem! I was fairly certain it was a DLL issue, but narrowing those down is extremely hard. It’s called «DLL hell» for a reason.

It is unclear who is at fault here — it could even be a bug in LabVIEW itself, possibly only affecting certain builds of LabVIEW on certain versions of Windows. The rules for how DLLs get loaded into memory are extremely convoluted and as a library writer I have very little control of it.

Specifically, MSDN states «If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL». This means that an application (maybe even LabVIEW itself) has already loaded zlib from the system directory and Windows doesn’t think it needs to load a different copy, regardless of the other precidence rules. Similarly if it is registered as one of the «KnownDLLs».

I could experiment with setting up a MANIFEST but I’d need your help testing as I cannot reproduce the issue. One final thing to try first would be putting the 3 dependent DLLs in the same directory as h5labview32.dll (the «lib/» directory) as that directory should have a higher priority than «resource/».

How extremely strange this only occurs when both scale-offset and deflate are used together!!

Cheers,
Martijn

Thanks Martijn. I have now put all the three dlls in the same folder as the h5labview32.dll, renamed the SysWOW64 version of zlib back to the original name, and everything runs fine (see attachment).

By the way, this «dll load tracing» approach with the process monitor is something which could turn out pretty useful to troubleshoot dll conflicts, since it tells you exactly what is loaded from where. Or maybe I’ve just discovered something known and obvious!

Glad to hear that worked — I’ll update the FAQ to reflect that. It is a good trick to use the process monitor to see what actually got loaded! I’ll have to remember that.

Cheers,
Martijn

Thanks Dan, those are definitely helpful resources!

Источник

I have a c++ library that I’m calling via the standard call library node in LabVIEW. I’m using 2017 VS to edit the c source files and 2020 32 bit version of LabVIEW. Consequently I’ve made sure to build new versions of my library in x86. I have not been able to nail down why I keep getting a 1097 error after the node call (I’ve included pictures of the function prototype that I’m attempting to call in the c header file, the node configuration interface, as well as a picture of the block diagram).

Additionally, LabVIEW reported these errors in the log when I restarted my development system:

DWarn 0x0E697B77: Caught exception in ExtCode call!

DWarn 0x50CBD7C1: Got corruption with error 1097 calling library Multilane_ML4039_Interface.dll function GetEyeDimensions

I’ve read that with this combination of errors, LabVIEW is catching an exception thrown by the .dll and this will prompt the library node to generator error 1097. This is often because of improperly configured parameters but as far as I can tell, my configuration is ok.

Any help is much appreciated.

Function prototype in .h file

Library configure node in LabVIEW

Block diagram containing library node

from Recent Questions — Stack Overflow https://ift.tt/37pAIEy
https://ift.tt/eA8V8J

Источник

Oscilloscopes & Data Loggers
Automotive
Press
Careers

Home
Products
Downloads
Forum
Support
Library
News
About

jswierk: Newbie; Posts: 0; Joined: Sun May 26, 2019 12:58 am

Error 1097 in 6000ExampleBlock

I’m trying to develop my own labview code that incorporates my new 6404C and I’m working through the GitHub examples first. For both the 6000ExampleBlock and 6000ExampleRapidBlock, I get error 1097, which I’ve traced back to first CallLibraryNodeFunction in the 6000GetBlock VI. I’m using 32 bit labview and the 32 bit SDK. I can’t figure out what the issue is and would appreciate any suggestions. Thanks!

Источник

Reported In

Operating System

Issue Details

Solution

Troubleshooting steps:

Was this information helpful?

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation

Search

You are here

error 1097 in test_suite and zipped-dataset.vi

Error 1097 in 6000ExampleBlock