I have program that uses a dll to make my device work. The driver for this device is installed on other computers.
My program works properly on my computer, but if I try to install it on another computer the dll no longer functions correctly (dll method can not find device).
But!, If I'm rebuild the program on the failing computer it works well.
What the reason of this behaviour?
Why it start work properly only after rebuilding ?
It could be binding to a different set of dlls that it is dependant on one one computer but these could be different (but compatible) on the other target machine, a recompile would mean that this code then linked against a different library version and functioned.
This is however a best guess as the question is not reall answerable in its current form
Related
I have come across this particular problem several times across several versions of the IAR embedded workbench (EW430 5.40.7 [EW 6.0], EW430 5.51.2 [EW 6.4], EW430 6.20.1 [EW 7.0]), but each time only after a long period of having no problems. The problem doesn't seem to have affected the other firmware developers in the office, so no help can be offered there. I'm currently on Windows 10, but the problems first occurred when I was on Windows 8.1 (same PC.)
The problem is that, for no obvious trigger, the IAR ide will start to hang until terminated (or it will just crash on one of the EW versions) on any attempt to change the active build configuration in MSP430 projects using the emulator.
From my testing, it appears to be directly related to something the IDE is doing with the emulator, as when the build configuration is changed, I can see the emulator menu in the menu bar disappear, then the hang happens. Under normal circumstances, the menu will disappear, but then reappear once the other debug configuration is completely loaded.
I have tried the default project "flashing the LED" to see if it was only my project - but if I select the msp430x4xx (C) - Debug, right click it and select "Set as Active" from the context menu, to make this the active project, the IDE also hung. I then reopened the EW IDE, and opened the LED flashing project again. The original 1xx asm project was the active project.
I then changed the settings of the 4xx (C) Debug project (without making it the active project) from the emulator to the simulator, and clicked OK. The program did NOT crash.
I then set the 4xx (C) Debug project as the active project and it did NOT crash. The simulator even runs without problems.
The version of the FET firmware didn't change from when the IDE worked correctly to when it didn't, and the FET is not even used at this point. It can be completely disconnected and the same results will occur.
I have tried the following, without success:
erasing the files in my project folder's settings subfolder
erasing the *.dep files in the project folder.
deleting the IarIdePm.ini file from AppData\Roaming\IAR Embedded Workbench
making sure none of the project files are read-only
reinstalling the program to the same location
removing and reinstalling the program to the same location.
What does solve the problem (until it reoccurs) is to reinstall the program, but to a different directory (for e.g., the default directory will be in program files (x86)\IAR Systems\Embedded Workbench x.x. Installing again into program files (x86)\IAR Systems\EWx (just so it is different) allowed that installation to work, but the old installation continued to fail.
Best advice so far (from our support person) has been to do the above, install to another directory and live with it, as it doesn't happen often.
Since it has happened to me on 3 occasions with 3 different versions of the program, I would like to know how to fix or prevent it! If anyone could offer anything to try (or even better, a straight solution :)) that would be greatly appreciated!
Cheers!
Since newer versions and updates on W10, it seems that old compatibilities are being removed from this OS. I have no direct solution for this problem since Microsoft does not promise support for old software and hardware. Even I tried to find a solution for that problem, and I found on the IAR website a list of IDE's and their compatible versions. (remember, old versions are not compatible)
( https://www.iar.com/knowledge/support/technical-notes/ide/windows-10-and-iar-embedded-workbench/ )
You will need to update your IDE and program version to a newer version if you plan to continue to use this IDE natively on Windows 10 or you may use Virtual machines with an old operational system (like Windows 7) to compile your program on old IDE.
P.S.1 I manually uninstalled KB4592449 recently updated and the program return to work natively. Probably it will continue working until this update (or other similar) being installed again on the computer, but probably there is any vulnerability that the computer will be exposed to, and in this case, I'm paying the price.
P.S.2 KB4580325 promotes the same behavior in IAR 5.11 on windows 10. Both KB's implement securities about the flash player - that I Don't use - then, I can securely uninstall it.
P.S.3 Since I updated my windows up to Windows 10 version 21H1 (compilation 19043.1165) AND I configured Windows defender to not be monitoring IAR IDE (IarIdePM.exe) disabling all protections available, everything works fine. But Remember: my program is original, not cracked or altered by anything, then I am secure to do what I did.
It is a 'natural' that software problem. Not found way of fixing it. The solution temporary is modify manually the file .eww for change of project active. The ultimate solution is to use another development environment.
I have a W2K8 box running some automation software.
Once of the drivers that I need to load for it adds a dll into a sub-folder of the program (in Program Files (x86)).
When the program tries to load the driver it spits out an error that it can't find the file. The location that it is looking for the file is correct and if I browse to that location the file is definaelty there.
Other drivers that use similar techniology (i.e. dll's in that same folder) are working fine, in that they find there dll and load up.
If I install the software on a XP/Win7/W2k3 OS it all works fine for the driver in question.
Is there something funky that the OS is doing that is not making the file visible to the program. The account that the servive for this program is running under is an admin account, the same account that I am loggedin with on the console.
I am told that the drivers are all C++ based drivers if that makes any difference.
Thats for any leads
Mick
Just off hand, it sounds like a permissions issue. That the application in question doesn't have access to the Program Files folder. Is this something you have checked? If not, I would start there.
I need to know how to make a software in Visual Studio(VC++ or VB) that can be run from a USB pendrive?
Is there anyway i can create this standalone software that doesnt need any installation in the PC in which the USB is plugged into?
Just save the executable on the drive. All referenced dlls also need to be stored there. If you have code access active you also need to make sure that the drive is allowed to provide executable code.
One more thought: If the system is linux ore mac then you should consder to switch to Java to be platform independend.
Yes, any native code application can run from a pen drive (so long as any dll's or associated files are also stored with it). .NET apps can also run... if the machine has the necessary run times installed.
Thanks to the gurus at StackOverflow. You guys are awesome. I posted on question on detecting idle time on a Compact framework application and got answers very quickly. When I tried the suggested solution on my Windows XP development box, I get this error
Unable to load DLL 'coredll.dll': The
specified module could not be found.
(On Windows XP)
After googling for sometime I understood that OpenNETCF libraries are trying to launch coredll.dll to detect the idle time but this dll is shiped with only Windows Mobile OS. As we are developing the application on a Windows XP PC and dont have access to Windows CE device now, we are struck with the problem.
Is there any way to get coredll.dll on Windows XP? Any other solution to this problem?
Updated: we are targeting the application for device running on Windows Mobile 6 Professional
I'm confused. The question was specifically about Compact Framework, which is for Windows CE. If you don't have your target hardware yet, then use an emulator.
In this specific case, the SDF is not P/Invoking to do this, it's using an IMessageFilter implementation. You could easily do the same for the desktop.
But that said, you simply can't develop a CF application targeting XP. What that means is that if you create your app using the full framework, targeting the desktop, and expect it to just run when you get your CE device, you're in for a big surprise. If targeting both OSes is a design goal, then there's a lot of work to be done, and most UI stuff is not transferrable (I'd actually recommend using different UI assemblies for the two targets and common business logic).
EDIT1
I guess to more fully answer the question of "can I get coredll.dll for my desktop?" the answer is a resounding "no". There are a multitude of reasons this wouldn't work (it's in ROM, it's hardware dependent, it's not actually a file, but fixed up to execute in place, it's compiled for a different OS, it may be compiled for a totally different processor, etc).
You have a couple options. You could try to create a desktop version of coredll.dll that exported all of the functions you want and proxies them to the kernel32, user32, etc DLLs. That's a boatload of work (been there, tried that).
You could try to write code that will work for both platforms. Doable, but also quite challenging.
The short of it is, unless you absolutely must target both, you don't want to try to. Get an emulator, virtual PC or some sort of eval system, and target that.
You can't run OpenNetCF in a Windows PC. You need to use a Windows CE emulator. This comes with the Windows CE SDK.
Write code that works for both platforms.
In our solution anything that is going to touch the platform is abstracted out to different objects. Therefore we have a IPlatformServices object (that returns stuff like IPowerManagement, IPrinter etc) we have two different implementations a PCPlatformServices and a CEPlatformServices and the one returned is based on the Environment.PlatformID value. In your scenario you want 2 different IdleDetector objects one for CE and one for Desktop. Aye its a bit of a pain to identify and abstract all this but you will need to do this is you want compatability between the two different platforms.
Our "PCPlatformServices" is mainly mocks in our case as we only want desktop compatibility to test things more quickly that don't interact with the hardware (like app code / business logic)
I have built a .dll under WinXP that claims it can't find DWMAPI.DLL when it's loaded. The problem is that this DLL is a Vista DLL, and this a known issue for XP users that have IE7 installed. The recommendation is to uninstall IE7 or repair the .NET Framework via Add/Remove programs. I did the repair, and nothing changed. I'm not about to uninstall IE7 since there must be a better solution that's not the equivalent of "reinstall windows".
I've read bad things about people who attempted to uninstall IE7, so I'm reluctant to go that route.
I am using C++ under Visual Studio 2003 (7.1). I don't see an option where I may have forced delay loading at application launch. I just used default settings when I created the DLL project. I did just now find an interesting option, Linker->Input->Delay Loaded DLLs, so I put DWMAPI.DLL in there to force it to be delay-loaded. However, I get this when linking:
LINK : warning LNK4199: /DELAYLOAD:dwmapi.dll ignored; no imports found from dwmapi.dll
.. and it of course didn't change a thing when trying to load my DLL. For the heck of it, I added the whole tree of DLLs that lead to DWMAPI.DLL, and I get the same message. (For the record, it's foundation.dll->shell32.dll->shdocvw.dll->mshtml.dll->ieframe.dll->dwmapi.dll .)
To be more specific about what I'm doing, I am writing a Maya plugin and get the always-helpful text in the script editor:
// Error: Unable to dynamically load : D:/blahblahblah/mydll.mll
The specified module could not be found.
//
// Error: The operation completed successfully.
//
// Error: The operation completed successfully.
(mydll) //
I used Dependency Walker to initially track down the problem, and that's what lead me to DWMAPI.DLL. These are the message depends gives me, and DWMAPI.DLL is the only thing that has a yellow question mark next to it:
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
Gerald is right. Maya is, in fact, using a different PATH than the Dependency Walker. My plug-in loads another DLL (for image processing) that lives in the Maya plug-ins directory and depends found it with no problem, but Maya didn't. I had to add ";plug-ins" to the PATH in Maya.env.
Seeing as this problem wasn't related to DWMAPI.DLL after all, but DWMAPI is a common problem, I'll post the best link I found about the DWMAPI issue on Novell's website here. Basically, most programs will have this warning in depends.exe, but if there is a delay-load icon next to it, and you are sure that the program won't directly or indirectly call DWMAPI, then it's fine. The problem is elsewhere. If the delay-load icon isn't present, then you have to look at the /DELAY and /DELAYLOAD options in Visual Studio. The fact that depends gave me a "warning" and not an "error" was a clue to the fact that DWMAPI is not being loaded automatically.
Based on your updated problem, DWMAPI.dll is probably not your problem. Dependency walker will always give you that error whenever you are linking to mshtml as it always checks delay loaded DLLs.
At this point my best guess is that you have your project set to dynamically load the runtime libraries and the search path for DLLs is being changed by Maya. So it may be unable to find the MSVC runtime DLL(s). I haven't developed Maya plugins in a long time, but I've had that problem with other apps that have plugin DLLs recently.
Try changing your setting in C/C++->Code Generation->Runtime Library to Multi-Threaded rather than Multi-Threaded DLL.
Aside from that you can try fiddling with Dependency Walker to make it use the same search paths as Maya and see if you can come up with another dependency problem.
As a last resort you can launch Maya in a debugger and set a breakpoint on LoadLibrary and find out which library is not being loaded that way.
This is a tricky one. There's really 2 main ways you will get this error.
1) You have your project set to force delay loaded DLLs to load at application launch. DWMAPI.dll is a delay-loaded DLL and thus normally will not be loaded unless one of it's functions is called. That won't happen on XP unless you're trying to do it in your DLL. But it's possible to set a compiler option to force your app to load the delay loaded DLLs anyway. If you're doing that, don't.
2) It's often a false error that you will get from depends.exe when there is another problem. Run your DLL through dependency walker and see if there are any other dependency problems. If all else fails, try uninstalling IE7 and see if the problem persists. If it is a false error, after you install IE7 you will see the real error. You can install IE7 again afterwards.
I had exactly this problem.
Sneaky problem that took hours to solve.
Anyway. I compiled my managed C++ application on the release machine. Got complaints from customers that could not run it, worked like a charm on all of our machines.
It turned out that the release machine was automatically patched one night a month ago with the ATL vulnerability fix, and so was all other machines also, except one XP machine.
That particulare XP machine could not run the application either. Installed the ATL fix (see link below), and voilá, every thing worked just like before.
http://www.microsoft.com/downloads/details.aspx?familyid=766A6AF7-EC73-40FF-B072-9112BAB119C2&displaylang=en
So lesson learned, always check your intermediate manifests (found the in debug or release directory), that will tell you what version of the DLL that the program have been linked against.
Hope it helps anyone.
Try changing your setting in C/C++->Code Generation->Runtime Library to Multi-Threaded rather than Multi-Threaded DLL.