Powerbuilder (ver 7) Runtime problems - runtime

We have an old Powerbuilder app running on Server 2000 and need to move it. I am having a problem with moving the Powerbuilder app ver 7.0, to a newer platform - Server 2003.
We basically moved the directory with the app in it and all the Dlls. Then I registered the ones that would allow it. We also had to set up Informix client-side software and verified that it was able to connect to the Database.
The app basically takes 2 parameters then checks for data in a remote database, then generates a return code to be used by another app. The return code we get is unexpected and I have no luck in looking up the number:
-1073741811
The app is run from the command line. When I run the app I get a Windows error that mentions Sybase and msvcr80.dll and a dump, and the return code mentioned above - Here is the error from the manifest text:
Server=watson.microsoft.com
UI LCID=1033
Flags=99088
Brand=WINDOWS
TitleName=Sybase Inc. Product File
DigPidRegPath=HKLM\Software\Microsoft\Windows NT\CurrentVersion\DigitalProductId
RegSubPath=Microsoft\PCHealth\ErrorReporting\DW
ErrorText=This error occurred on 2/14/2013 at 7:56:14 AM.
HeaderText=Sybase Inc. Product File encountered a problem and needed to close.
Stage1URL=/StageOne/cert_lsi_exe/7_0_3_10180/msvcr80_dll/8_0_50727_6195/0001e6d5.htm
Stage2URL=/dw/stagetwo.asp?szAppName=cert_lsi.exe&szAppVer=7.0.3.10180&szModName=msvcr80.dll&szModVer=8.0.50727.6195&offset=0001e6d5
ErrorSig=AppName: cert_lsi.exe AppVer: 7.0.3.10180 ModName: msvcr80.dll ModVer: 8.0.50727.6195 Offset: 0001e6d5
DataFiles=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.mdmp|C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\appcompat.txt
Heap=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.hdmp
ErrorSubPath=cert_lsi.exe\7.0.3.10180\msvcr80.dll\8.0.50727.6195\0001e6d5
I am surprised by the msvcr80.dll request, because this app was written around 2003 and I didnt think that c compiler was at ver 8 yet. I have used Dependency Walker and see no complaints there. I am probably in DLLHell with this thing, though... does anyone have any ideas what to look for?
Thanks in Advance!

I still have a few PB 7 applications around.
Did you try Application Compatibility?
Navigate to the folder and right click on the executable and choose the Compatibility tab.
I suggest trying
Run this program in compatibility for Windows XP (Service Pack 3)
Privilege Level [x] Run this program as administrator
You may need to use Windows XP (Service Pack 2) or an earlier version of Windows.

Related

deployed pb App transaction not connected

I have deployed a PB App created with PB12.5 Classic. Its a PB winform app. I have managed to deployed it on a test unit to test its performance. I have created a custom runtime packager.
this runtime packager that i have created consists of basic PB runtime DLL, which is the PBDWE125.dll, PBSHR125.dll PBSNC125.dll, PBVM125.dll as per sybase's instruction in infocenter.sybase.com.
i have also packaged microsoft dlls which is the atl71.dll, libjcc.dll, libjtml.dll, msvcp71.dll, msvcp100.dll, msvcr71.dll, msvcr100.dll and nlwnsck.dll.
all of these dlls are installed in C:\Program Files\Sybase\Shared\PowerBuilder.
my problem is, my PB app is running BUT WHEN I TRY TO ESTABLISH CONNECTION my database server it prompt "Transaction not Connected"
is it the PBSNC problem? i tried registering it using regsvr32 and it didnt work. i have used PB runtime packager but still no luck. i have tried the app path registry and link it to the directory stated above and still no luck...
my question is
is there anything that i can do to make this work?
win 7 has c++ runtime libraries installed already right?
what can be the cause of "transaction not connected" error
what can i do to make it work?
note:
i have user access to the database server
i can access the database server
the app is working when the PB IDE is installed
please enlighten me! thank you :D
Does the computer that the app is deployed to have the SQL Server Native Client runtime installed? (I'm assuming you're using SQL Server because you mention PBSNC125.dll.) Here's some info from a blog post I wrote a while back (I was using PB 12 and SQL Server 2008, so things may be different for you.)
Files Required
On your client machines, in addition to the PB runtimes (including PBSNC120.dll, which is for SQL Server), you also need to install the SQL Server Native Client runtime. These come as an msi installer package from Microsoft. When you install the SQL Server client, you'll need to do so as an administrator. Otherwise you'll get a cryptic error message along the lines of "0: -1".
There's a 32-bit and a 64-bit version of the runtime. The 64-bit version won't run on a 32-bit version of Windows and vice versa.
Footnote: My project used PowerBuilder Classic version 12.1 and SQL Server 2008
"Transaction not connected" usually comes from a DataWindow being given a transaction object that isn't connected to the database. It sounds like there isn't much error trapping when you connect to the database, and you're getting a down stream symptom. You need to add error checking to your CONNECT routine, and that will give you more clues as to what is going on.
One of the more common problems with connections on deployment is when programs try to read connection parameters from an INI file, and on deployment the app can't find the INI file, so with no error checking on reading the INI, the program is trying to connect with an empty transaction object and fails. However, the information you've given us is too late to have any clues whether that is the problem or not.

Does a Lazarus program need special permissions to run on Windows?

I built a Lazarus program and it's now in exe form.
I am able to run it on two of my computers running XP and Vista.
However, there are other computers as well running XP, Vista and Win7 but I cannot get it to run at all on them.
There are no errors, nothing... Has anyone else had this issue?
The program is connecting to a postgres DB on my LAN server.
Any idea on fixing this is really valued.
NEW INFO:
Maybe I'm wrong but here's a thought... On the development machine, I initially got an error like **libpq.dll* not found when I first tried to connect to postgres. Then after setting the path, it was fine. I'm thinking now if it cannot find that library and that's why it's not able to run.
If this is the case, should my line Application.OnException:=#CatchErr; catch the error? If not how else should I check if this dll or anything else is missing?
First, a sincere and big THANK YOU to Marco and MArtyn for the great tips and guidelines hat got me thinking of this strange issue.
Here's what happened...
I installed a fresh copy of Windows 7 and XP. As usual it did not work.
Then I suspected the old problem of libpq and then I copied libpq.dll from my working OS and put it in the application folder. By the way this machine has no Lazarus or Postgres. The moment I did this, I got my first error message saying that msvcr100.dll was missing.
And then I copied that as well. So the cycle of copy pasting went on for each and every error until I had finally brought these files to my 'non-working'.
libpq.dll - 9.2.1.12263 - PosgreSQL Access Library
msvcr100.dll - 10.0.40219.1 - Microsoft C Runtime Library
ssleay32.dll - 1.0.1.2 - OpenSSL Shared Library
libeay32.dll - 1.0.1.2 OpenSSL Shared Library
libintl.dll - 0.18.1.0 - LGPLed libintl for Windows NT/2000/XP/Vista/7
Once these files came in, the problem was gone!
Now the program works great :)
Thanks for all your inputs!
I now have to see what the above files have to say about their licenses as I have to distribute the app to other users. But I'm glad at least we figured out the problem.
No, base Lazarus programs don't require special permissions. Of course it could be that a specific functionality in the program requires special permissions (like access to ports below 1024, access to certain paths etc).
Also be aware that EXE's downloaded from what the system considers insecure sources (internet, certain kinds of shares) might be blocked by default. If that is the case, if you take the properties of the .EXE in windows explorer, there will be an "unblock" button.
Anything network related of course requires proper configuration of the firewall. The popups that query you might not always come, in case of doubt configure the firewall manually.

The procedure entry point _except_handler4_common could not be located in the dynamic link library msvcrt.dll

I am using "Microsoft Visual Studio" to work with an "MFC application".
I am using "Installshield" to create the setup file for this application.
I get a "setup.exe" file.
If I run this setup on a "Windows XP 32 bit" machine, the installation ends properly.
Yet, when I try to start the installed program, I get the message:
"The procedure entry point _except_handler4_common could not be located in the dynamic link library msvcrt.dll."
In debug mode, I can't find the moment the error occurs because whatever the breakpoint I put in the code, the message appears before reaching the breakpoint, I guess at the very beginning of the program execution...
Note: It works for Vista 32 bit and Seven 64 bit.
It appears lots of people do have the same problem but I couldn't find a solution for myself.
Can you help?
Thank you.
Welcome to the world of DLL hell and application dependency analysis.
I found that DLL on my Win8 machine in the SYSWOW64 (32bit System32 folder ) with version 7.0.9200.16384. Looking at it using Dependency Walker I can see it in fact exports the function you are looking for.
I also see on my InstallShield machine a merge module called MSVCRT.MSM that redistributes version 6.00.8797.0 of this file. However when I look it using Dependency Walker, I see it has the exported functions _except_handler2 and _except_handler_3 but not _except_handler_4_common.
So therefore you need a newer DLL and that merge module won't help you. Microsoft used to have this cool website called DLL Help Database that told you all the versions of a file and what shipped them but sadly they killed it.
BTW, I can also see that this DLL is installed with Windows these days. Windows XP? I'm not so sure as I'd have to fire up a VM and look.
A couple possible resolutions:
Find out what SP or Hotfix of Windows fixes this and make it a dependency of your MSI.
Grab the DLL from a Win 8 machine and add it to your INSTALLDIR and deploy it privately.
One final note. This is either caused by the version of Windows XP comes with an old version of the DLL ( A related KB Article says it does ) or that a third party application whacked the DLL causing the problem. Some more study is required here.
I recommend you first try installing the MSVC Redist version 2008. That one does include the implementation of the missing function.
This post is old but I wanted to leave my solution since this problem was hell to me. My python app was working for Linux, Win7, 8 and 10 but WinXP refused to work with that message.
I was using py2exe to get an executable and it will put some DLLs along with the exe file.
Deleting some dlls from the exe's directory was the only thing that make the app work in XP and continue working in the other systems:
[ "POWRPROF.dll","IPHLPAPI.DLL","USP10.DLL", "DNSAPI.DLL" ]
Also distributing "Microsoft.VC90.CRT" directory along with the exe file, with it's manifest and DLL files.
I hope this will be useful for someone, since it took me weeks to figure it out.
(i know the OP wasn't working with python, but the error is just the same)
Your program has a dependency which is not being satisfied on Windows XP. You might try using Dependency Walker to identify it, or you might check for known limitations. For example, Visual Studio 2012 doesn't support Windows XP until update 1 and a build option change - is that what you're using?
The problem was probably because you might used a corrupted DirectX version on your Win XP. It happened to me as well because I randomly downloaded a DirectX setup which was corrupted and caused these. The solution I did was is I deleted all the files that has anything to do with directX from C:Windows/System32, deleted the directX from add/remove program as well and completely removed the whole registry key from regedit. Local_machine/software/microsoft/DirectX... What I did then was found a original values and keys for DirectX 9 on the net and made a new registry key.
The DirectX folder was once completely and originally back on regedit and it showed in dxdiag that the directX is installed.
In case you encounter crashes in the game, I suggest you to download .NET Framework 3.5 Service Pack 1 and then make a backup on your PC (If you're not using nVIDIA graphic cards like I do, I use ATI Radeon) and download nVIDIA PhysX system software driver and see if it works. (You need nVIDIA phydX drivers to run this game without crashes only if you use Win XP, the problem shouldnt encounter on Win 7) In case the drivers screw up your PC (The nVIDIA PhysX one) you will be able to restore your old PC function before those drivers (If you made a backup of your PC, I suggest using Acronis Boot for backups) it means you're totally out of luck if you're not able to get the nVIDIA PhysX on ur for example, ATI graphics on Windows XP, because without nvidia physx, on Win XP, Metro wont run, while on Win 7 / Vista / 8 it should.
I just installed the latest VS 2017 and was running into the same problem. I googled everything but couldn't find any solution, so I just defined it myself:
extern "C" int _except_handler4_common() {
return 0; // whatever, I don't know what this is
}
I've spent the last 8 hours picking my code apart with this exact same error and it turned out to be a line of code in my application, specifically a check for IPv6 support in the OS:
conf.IPv6Disabled = !(Socket.OSSupportsIPv6);
I commented that line out and voila, error disappeared.
This problem persists to every software or game that requires windows 7 or 8 or vista but is made run into windows xp. So if you want to resume or start your program you need to upgrade your windows to 7 or 8 or vista as per the system requirements of the program.
HOPE IT WAS HELPFUL
THANKS

visual studio application stopped working on windows 7

I have made an application in visual studio 2010 on a windows xp computer. When I compile the release version and run it on a windows xp computer, it runs fine.
When I on the other hand try to run it on windows 7 I get the "This program has stopped working" error message. Running the application in compatibility mode doesn't change anything. Can someone tell me what I can try to do?
Thanks.
With the information you provide, it might be a windows 7 vs xp problem or that you don't find any resource that you are looking for. If I were you I would:
Get sure that app was compiled by any cpu
Check windows error log to see if there is any message
Run app as administrator
Use error handling (try/catch) to see exceptions by showing them in UI or logging to a text file.
EDITED: TRY-CATCH example
Try
//CODE
Catch ex As Exception
Dim writer As New StreamWriter("C:\MyLog.log", True, System.Text.Encoding.ASCII)
writer.WriteLine(ex.Message)
writer.Close()
End Try
I ran across this issue also. As my solution was completely different, I thought I would share just in case someone else found it relevant.
My problem was that in my project references I had two references to Adobe Acrobat DLL files. I was getting the error on my new client machine because it didn't have Adobe Reader installed (which installs the DLL's that my project references). Once I installed Adobe Reader, my program installed properly.
The interesting part of debugging this is that no TRY/CATCH block would have caught it. Apparently the check for reference happens before the code is run. You literally just get the generic message "ProgramName has stopped working".
Just FYI...

Unable to load VB6 OCX in Windows 7 Error 372

I'm working on an application developed for Windows XP SP3, using VB6. I'm currently in the process of getting it to work on Windows 7, but am encountering a problem with one of our custom OCX files.
When attempting to load a form that contains an instance of the control contained in the problem OCX, the following error is produced:
Failed to load control 'x' from y.ocx. Your version of y.ocx may be outdated. Make sure you are using the version of the control that was provided with your application.
I've checked the version numbers and they're all correct and referencing the proper version. The OCX registers fine, and all the expected registry entries are present.
Inspection with DependencyWalker shows no missing dependencies.
The software works fine under XP, and this is (seemingly) the only issue when running on Windows 7.
Interestingly, if I run through the VB6 IDE using a VB6 group (with the offending OCX part of the group, and the application the startup project), I don't have the issue. Running the application on it's own through the IDE still presents the error.
Any ideas on what could be missing which would cause the application to throw this error?
Error occurs on both Windows 7 Professional and Home Professional, both 32 bit.
This is almost certainly an interface compatibility problem. COM interfaces are versioned entirely separately from your Major/Minor/Revision numbers, which are little more than comments except as used by Installer.
Somewhere along the line you broke binary compatibility, and you are trying to deploy a library with a newer interface than your application was compiled against.
These version numbers are found in keys such as:
HKEY_CLASSES_ROOT\CLSID\{class Id GUID}\VERSION
Your program needs to have its old reference to the OCX removed, a new one set, and then it must be recompiled. This also means deleting any instances of the control and adding them back one by one.
I doubt this is a Windows 7 issue.
I would suspect this is a UAC problem. Try turning UAC off to see if that solves the immediate issue. If it does then you have to regsiter everything using 'run as administrator' and/or create a manifest for you application.
Sounds like on of the controls included in your OCX is having issues loading, not a general registration error. Look at the constructors for x control, and see if they are doing anything that disagrees with UAC or such. One way you can debug this is put some kind of a break before the control is initialized, and debug the application from Visual Studio (remember to create the PDB's in VB6), and then carry on from the break to see why the control isn't initializing.

Resources