I have some VBscripts that automate IBM Personal Communications
Since I have to use the version 14 (64 bits) sometimes I get errors:
If I use the function CreatObject the error is: The specified module could not be found.
If I use the Wscript method Wscript.CreateObject the error is: WScript.CreateObject: Could not create object named "PCOMM.autECLConnMgr.1"
I have tried 2 ProgID for each of the 4 DLL
"PCOMM.autECLConnMgr" or "PCOMM.autECLConnMgr.1" "PCOMM.autECLPS" or "PCOMM.autECLPS.1" "PCOMM.autECLConnList" or "PCOMM.autECLPS.1" "PCOMM.autECLOIA" or "PCOMM.autECLPS.1"
I'm using LENOVO workstations with Windows 10 Enterprise Build 1809 64 bits
And also tried
C:\Windows\SysWOW64\cscript and C:\Windows\System32\cscript
Both works and both sometimes return the errors
Also have tried 2 different workstations in spite of those machines have the same "image" of software...
With IBM PC Version 12 this didn't happen!
And here is my pain... The error happens just the first time the script runs... Then okay.
I even can't induce the error !!
Any hint would be appreciated.
João
Related
Thank you for your reply and comments.
Let me describe the situation more detailedly.
I use Visual C++ 2008 to write a small application that will invoke MAPI. I use MAPIStubLibrary to support both 32bit and 64bit MAPI. MAPIStubLibrary can be found at https://msdn.microsoft.com/en-us/library/office/cc963763.aspx#sectionSection2 . It works on other versions of Outlook and most of the systems. However, under Windows 10(32bit) with Office 2016(32bit) installed, when I execute the following statement to initialize MAPI:
MAPIInitialize(NULL);
I will get the above error message "The operating system is not presently configured to run this application". And there will be an unhandled exception raised from the function GetDefaultMapiHandle(), which is in StubUtils.cpp, part of the MAPIStubLibrary.
The exact line that cause the exception is:
hinstMapi = LoadLibraryW(wzPath);
It seems that MAPIStubLibrary is trying to load 32bit MAPI but fails. wzPath is pointing to olmapi32.dll instead of msmapi32.dll.
In the error message, if I click “OK” button in the error messagebox, the application will continue running without problems. However, the error message is still frustrating and confusing the users. Therefore, how to eliminate the error?
Thank you very much.
This usually happens when you are either loading a wrong MAPI dll (e.g. olmapi32.dll instead of msmapi32.dll) or if your app is running in the compatibility mode (do you include a manifest?) and the MAPI system ends up patching wrong Windows API functions assuming an older version of Windows.
I have an application written in Delphi XE3 (Originally Delphi 7) with a MySQL database. It was running on 5 computers on a network. Two of the computers were on windows 7 while 3 were still windows XP. The client recently upgraded the 3 windows XP computers to windows 7 x64 (3 brand-new identical machines). The program is running fine on one of the new computers but on the other 2 I get the error message "A problem caused the program to stop working. Windows will close the program and notify you if a solution is available". The program seems to crash at the end of the FormActivate procedure after it had verified the password and connected to the database. The MySQL server is up and running. I can access the database on the problem machines locally and remotely successfully.
I have searched the Internet and some websites suggest that this error is a protective mechanism from Windows triggered by a thread to system files, indefinite loops or memory problems – none of which are applicable to my program.
I have since reformatted the 2 problem computers and reinstalled Windows 7 again but it did not solve the problem.
The DependencyWalker output on both problem and working machines (and on my development machine) are identical :
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
With regard to different CPU types - in all instances the application is x86 and the rest of the modules are x64. This could be a 32-bit-64-bit problem but the program is running on all the machines except for 2 problem machines.
The Windows Event Viewer reports the following error:
Faulting application name: February_2014.exe, version: 1.0.0.0, time stamp: 0x52fa3b19
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18229, time stamp: 0x51fb1116
Exception code: 0x0eedfade
Fault offset: 0x0000c41f
Faulting process id: 0x1510
Faulting application start time: 0x01cf28a57840f88d
Faulting application path: C:\dgpa dgr\February_2014.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: bd26ca27-9498-11e3-9479-7c050710b013
I have searched the Internet (and Stackoverflow) for KERNELBASE.dll but could not find anything useful.
I have asked for help on Windows Technet without success
http://social.technet.microsoft.com/Forums/windows/en-US/ef52b2e1-237d-436f-952f-7cdecdb48337/a-problem-caused-the-program-to-stop-working-windows-will-close-the-program-and-notify-you-if-a?forum=w7itprogeneral
The program is running without the hitch on my Windows 7 x64 development machine so I cannot replicate the problem/error that I am experiencing at my client. Has anybody had a similar problem? Any suggestions for the cause/trigger of the Error and how to solve it?
UPDATE
I got the following report from madExcept but I have no idea what it means
If you include a ClientDataSet in your application you need to deploy midas.dll with your application, or you have to manually add the MidasLib unit to your project's uses clause (for example)
program Project1;
uses
MidasLib,
Forms,
Unit1 in 'Unit1.pas' {Form1};
For a detailed explanation see the article of Cary Jensen on the topic.
The screenshot from madExcept is telling you that your program is raising an exception at startup, before you call Application.Run. The root of the exception is in the call to Application.CreateForm made in your project file.
The top-level exception handler is contained in the main application message loop that is implemented in Application.Run. Because you have not yet started the main application message loop, there is no exception handler.
This means that the exception leaks out of your application and the system has to handle it as best it can.
I don't know how to fix your specific problem, but the madExcept diagnostics tell you where to start looking. Ideally you would like to be able to debug this scenario in the IDE. Once you can do that it will be much easier to track down.
Fundamentally, if you leak exceptions out of your startup code, you will encounter such error dialogs.
I know of a few things that could be potential sources of the issue. First is the space (blank) in the path name where the application is running. Trying moving app to a subdirectory with no spaces in the path name. Second try running in Admin mode if you are not already. The answer that references "midas.dll" is another one. With the additional warning that Delphi used to install a copy of midas.dll in the Windows\System32 directory. Make sure that your version of midas.dll came with the version of Delphi you wrote the code in (and make sure that there isn't another older copy being found before the one you intended. Depends.exe can help show the path to the dll it loaded. Also have you tried running the app using "XP Compatibility"? Does the issue go away? Also have problems with DB components on a DataModule form in Delphi before. If you have a DB component with a AutoConenct on (or Streamed connection), it can cause unusual errors. Best to leave it disconnected and connect it in your source code at runtime. Last thing to try, look at the Windows services and see if the Performance Logs are running prior to launching your app. A weird one, but I've seen it.
I am running some legacy VB6 code on a 64bit Windows 7 machine and am running into some weird errors.
my code blows up here:
with the message:
a whole section of code above this error handling is precededed by:
On Error GoTo ErrorTrap
ErrorTrap being my For Each loops seen above.
What causes this type mismatch?
MyError has to be a Variant type: in VB6 For-Each enumeration has to be done using a Variant.
Use
Dim MyError As Variant
instead.
If your code has anything to do with ADO then it could be the known VB6 ADO & Win 7 issue described here: http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13. It seems that typelibs changed in Win7 Sp1 which could make VB6 apps compiled on prior platforms crash when run on Win 7 or apps compiled on Win 7 crash when run on prior platforms. The linked article provides some suggestions for solutions, the easiest of which if you have the source code is to switch to use late binding when viable.
I have set up the QODBC driver and was able to connect to my QB file and run queries in the VB Demo 32.
I am looking at one of the Sample Files, found here - http://support.flexquarters.com/esupport/index.php?/Default/Knowledgebase/Article/View/506/57/examples-of-how-to-use-qodbc-via-visual-basic
I did what this article said - copied all of the text into a text file, saved it as "Customer.vbs". I created a Customer named "Kim Garland", closed the dialogue box, double clicked on the file. The msgbox never displayed, and this error message came up - "[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application; Code: 80004005; Source: Microsoft OLE DB Provider for ODBC Drivers"
Any idea what is going on here? After looking through the knowledge base, I thought it might have something to do with 64-bit vs 32-bit... but that didn't seem to get me anywhere. I do have Visual Studio installed, but don't quite know enough about VB6 apps to know what I'm doing.
EDIT
By the way, the line that is giving the error is:
oConnection.Open "DSN=Ben Test 2;OLE DB Services=-2"
I originally was using the same exact line that was in the article that I linked to, but that was not working either. I used the c:\windows\syswow64\odbcad32.exe to create a 32-bit DSN called "Ben Test 2". It didn't seem to change anything.
Please take a look at the Microsoft's website where they talk about it.
It is not VB issue, it is 32/64bit issue as you suspect.
http://social.msdn.microsoft.com/Forums/en/sqlgetstarted/thread/702f0d9b-6cb9-49cf-9953-80d059711e60
Since you are using 64-bit system, your VBS will be execute as 64-bit (by default).
QODBC is 32-bit driver, and can work with 32-bit applications. A 64-bit applications cannot talk to a 32 bit Driver and same is with 64bit application to 32 bit Driver.
For 64-bit applications use QRemote (which is a 64-bit Driver driver).
Solution 1
You can try to use QRemote to bridge QODBC and your application. Here is an article about how to use QRemote:
http://www.qodbc.com/qremoteconnect.htm
Solution 2
and there is another solution for you issue. Please call your VBS as 32 bit. Please follow the steps below:
1) Click Windows Start
2) Click Run, in the window, type "%windir%\SysWoW64\cmd.exe"
3) Click OK, then type "cscript vbscriptfile.vbs" in the cmd window
This will make your VBS run in 32-bit mode even thou you are in 64-bit machine
-Regards
Rajendra Dewani
Does anyone know of any issues with the ILClone() function on Windows 2000? Is it fully supported? MSDN says it runs on Windows 2000 but I have a user reporting that my program will not run on Windows 2000 because of that function.
EDIT: I was able to get a hold of a Win2K system and I can confirm the issue.
Shell32.dll version installed is 5.0.3700.6705. The error message shown when running the program is: The procedure entry point ILClone could not be located in the dynamic link library SHELL32.DLL
iirc ILClone was available on Windows 5, but it was exported from shlwapi.dll, so you had to load it using LoadLibrary & GetProcAddress() to be compatible.