I have a LV program that calls an external library via wrapper functions that I downloaded via VI package manager (libxml2). This program works fine on computer A (Win7, LV2015 32-bit). Since it is meant to be portable, I have installed it on various computers (Win7) where it runs well, except for computer B. There, it throws an Error 1097 when calling the external library. The libxml2 package is obviously installed and I can see it on the Functions palette. Could it be due to the differing versions of Windows, or due to conflicts between Labview 32- and 64-bit? I open and run my program with LV 32-bit.
Computer A:
Labview 2015 (32-bit)
Windows 7
Computer B:
Labview 2015 (32-bit)
and Labview 2015 (64-bit)
Windows 10
It is very likely that the call parameters to the dll need to be changed between the 32bit and 64bit labview vi, this is indicative of the error 1097. If you have pointers or need to reserve memory these can have different size between the 64bit and 32bit variants.
For more help code needs to be shown also a more detailed error description if that is provided.
I was able to solve the problem: probably, there were race conditions and sometimes the DLL was getting illogical random input. It had nothing to do with the system.
Related
Im developing continually an inventor Addin in VB.Net in visual studio 2019 ,
i have multiple machine different builds , but once in a while some machine just don't want to load the Addin f.e. the current version i have now works on all machines except one AMD machine .
When i compile the same project with the same settings no changes at all on the AMD machine with ANY CPU build option it runs without problem . When i do it on my primary developing machine it does not work on this other computer.
I checked dependencies with dependency walker , i do not get any error messages .
When i make breakpoints in DEBUG mode and debug dll compilation in the first methods called in the "StandardAddInServer.vb" file it does not reach it on the AMD machine when it is compiled on the Intel machine. But in reverse it runs smoothly .
I have no idea what this could be and I'm only speculating that is has to do with AMD/Intel difference of the machines . Any help would be appreciated to come to a solution.
Inventor 2018.3.7 Professional Build 287 is on the Intel i7-4771 machine Visual Studio Community 2019 16.3.9 , .NET 4.8.03761
Inventor 2018 Professional build 112 is on the AMD Ryzen 7 3700X machine Visual Studio Community 2019 16.7.2 .NET 4.8.03752
Any more information which could be helpful will be provided gladly .
Well.... i tought lets make the maschines identical in regards to software .. i started installing inventor updates one by one at Version 2018.3.1 the Addin magically was working .... so i hope i help somebody if the , addin automatically unloads without any error , its probably autodesk inventors fault ...
Are you using ANY CPU ,or are you forcing the project to a given bit size?
If you don't set this, and leave it at ANY CPU? Well, if you launch the application from Visual Studio (such as installing on that target machine), then the application will run as x32 bits.
HOWEVER if you launch the program from the windows command line (command prompt).
Well, if you use the x64 bit command prompt, you get a x64 bit running - in-process program. If any of your external .dll's or libraryes are x32 (or not compiled with ANY cpu), or you using any un-manage code libraies (say like ghostscript or some such)? Then your program will run (or try to) as x64 bits.
However, if you launch a x32 bit windows command prompt (there are two of them - one is x32, and one is x64). So, if you launch the .net exe (your program) from a windows x32 bit prompt, then your program will run in-process as x32 bits.
So, be careful here. Using ANY CPU from Visual Studio will ALWAYS get you a x32 bit program - including debugging. But RUNNING the program (launching outside of VS) will not always be x32 bits.
And the above behaviours seems to explain your issues/problems on the AMD machine. It was NOT that you installed VS on that machine, but that using VS to launch your program in fact FORCED it to run as x32 bits.
Bottom line:
do NOT use ANY CPU unless that is exactly what you need, and that you are VERY sure any external libraries are also compiled as ANY CPU, or in fact that any external libraries doe NOT USE any un-managed code.
All in all? I would config your project to force run as x86 ALWAYS, and thus you not get some surprises of code not working.
I doubt very much that the AMD CPU is the issue, and installing VS only worked because of forcing your project to run as x32 as opposed to x64 bits. It has zero to do with AMD here.
You could try with a former framework version like 4.6.2. That should fix the problem. It could be that the newer service packs of Inventor can deal with addins created with newer .net versions. When 2018 Inventor was released, .net 4.8 was not available.
Was Albert wrote is true as well. If the architecture of your dll doesn't meet that of your host process, it can't be loaded. A 64bit process can use 64bit dlls only whereas a 32bit one can deal with 32bit dll only. A .Net project won't be compiled by Studio into fully functional machine code (nowadays you can do this as well), but intermediate code only, which will be compiled finally by the .net framework on the target machine. If anyCPU is selected, you don't have to provide different versions for different hardware because of this behaviour.
I am working in a 64-bit Windows 7 environment and running a 32-bit version of LabVIEW.
I need to link up a specific instrument to LabVIEW, using a LabVIEW library which was given to me by the company that made the instrument. The library includes calls to a couple 32-bit DLL files which were also given to me by the company.
LabVIEW is having trouble reading those DLL files, and whenever I try to open a file I get a popup message that says "Error loading DLL". Is this because of a 32-bit/64-bit incompatibility, or is it due to something else altogether ?
Thanks,
Check the DLL in the dependency walker, there must be a DLL dependency problem.
You should be able to call at 32 bit DLL from 32 bit LabVIEW in a 64 bit OS. I believe the issue is something else.
I'm using the Crystal Report 10 viewer ActiveX control in an Access App I've written. Works great in Office 2003 on 32bit versions of Windows. The problem arrises when I try to run the program in 64 bit Windows (with 32bit Office). I get the following error:
Run-time error '429': ActiveX component can't create object
I get this error on the following line of my VBA code.
Set rdApp = CreateObject("Crystalruntime.application.10")
How can I get this to work in 64bit?
I don't have any specific experience with Crystal Report, but I do have some experience with installing components on a 64-bit Windows environment that were intended for 32-bit Windows, so here are some general suggestions of things to try:
Before installing, try loosening the security privileges - I have Windows Server 2008; on this OS, they're under Start | Administrative Tools | Local Security Policy. Many old installers are thwarted by these controls. You'll want to return them to their defaults after the install.
Make sure that you run the installer with admin privileges (right-click; run as Administrator).
Examine the installation log for Crystal Report - it may indicate a failure registering a component. In one instance, I was able to get the installation working by running the command to register the failed component manually, on an administrator-privileged command line (the command was in the log).
If acceptable, try to create a Windows Virtual Machine running a virtual Windows XP, and try the installations there (this might be a bit tedious, due to your need for MS Office).
Take a look at VMWare's ThinApp - this is intended for packaging applications for administrators, but this was the solution we ended up using to shield one of our 32-bit apps from Windows 64-bit perils
Hope this helps; we struggled for awhile trying different things to get our legacy apps working on a 64-bit environment.
a few years ago I was a Windows application developer.
In the last years I am dealing with kernel and system software.
Now:
I have a customer who tells me that he has a 64bit C/C++ application with
specific functionality. This functionality is a dongle request
and comes from an external 32bit dll.
He says that this functionality is given although I can not see the
DLL in memory.
If I delete the DLL, the 64bit application is still loaded.
That means the 32bit DLL is somehow a static part of the 64bit application.
Can that be true nowadays?
And if so how can I achieve that with Visual Studio?
Best regards
Burkhardt
Based on what I have found on StackOverflow.com it is not possible to load a 32-bit DLL from a 64-bit application (or vice versa) dynamically or statically. There are however a few workarounds.
See the following:
https://stackoverflow.com/a/12938217/184528
https://stackoverflow.com/a/5720902/184528
https://stackoverflow.com/a/11642165/184528
My company has a VB6 application using Crystal Reports 7 which a client has asked to be installed on Windows 7 32 bit. It is currently installed on Windows XP 32bit SP2 machines at the client. Connection to the DB is done via ODBC to SQL Server 2000 instance on another server.
On Windows 7, the installation works fine, however when you try to open the application, the error is given.
I have looked at the following:
Registering all the dll's and ocx files using regsvr32. Some will not register as they either are registered already or the following message is given "Make sure that "[name].dll" is valid DLL or OCX file and then try again." I read this forum thread regarding this: http://social.msdn.microsoft.com/forums/en-US/vblanguage/thread/0653f685-4526-45d9-89f3-8c479a6b4c62
Monitored the opening of the application using a ProcessMonitor application to try and spot if there is a missing dll or ocx file - this does not seem to be the case.
Reviewed the application according to this list and nothing seems to be against these guidelines
I've noticed two items in the knowledge base that relate to this
http://support.microsoft.com/kb/281848 - the comdlg32.ocx bundled with the application is version 6.0.81.69 and the one in the system32 folder on the dev machine (WinXP 32 bit) is 6.1.97.82. However if this was the issue then surely it would not work currently?
http://support.microsoft.com/kb/184898 - I'm not sure how to confirm that this is the issue
Finally, due to complexities, I am not allowed to make code changes to this application. Even if I was, I'm not a VB6 programmer, just the guy who got the terribly support project! If code changes are required, then I'll have to investigate using WinXP mode.
Update: I get the same error in XP Mode. That's a Win XP with SP3 VM. This runs on a Win XP SP2 VM, is there potentially something in SP3 that would have caused this to occur? Or is it just a fact of it being XP Mode?
I got the same error but I solved by using regsvr32.exe in C:\Windows\SysWOW64.
Because we use x64 system. So if your machine is also x64, the ocx/dll must registered also with regsvr32 x64 version
The file msrdo20.dll is missing from the installation.
According to the Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7 this file should be distributed with the application.
I'm not sure why it isn't, but my solution is to place the file somewhere on the machine, and register it using regsvr32 in the command line, eg:
regsvr32 c:\windows\system32\msrdo20.dll
In an ideal world you would package this up with the redistributable.
This download fixed my VB6 EXE and Access 2016 (using ACEDAO.DLL) run-time error 429. Took me 2 long days to get it resolved because there are so many causes of 429.
http://www.microsoft.com/en-ca/download/details.aspx?id=13255
QUOTE from link:
"This download will install a set of components that can be used to facilitate transfer of data between 2010 Microsoft Office System files and non-Microsoft Office applications"
You say it works once you install the VB6 IDE so the problem is likely to be that the components you are trying to use depend on the VB6 runtime being installed.
The VB6 runtime isn't installed on Windows by default.
Installing the IDE is one way to get the runtime. For non-developer machines, a "redistributable" installer package from Microsoft should be used instead.
Here is one VB6 runtime installer from Microsoft. I'm not sure if it will be the right version for your components:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7b9ba261-7a9c-43e7-9117-f673077ffb3c