T
tomb1818
Guest
I know this is a long shot but I have no where to go now.
I have three products on the market. They are released as 64 bit version (with AnyCPU) and 32 bit versions. This 64 bit one is solely due it a specific driver not working correctly on the 32 bit code.
The products have been out for many years. This week, I released an update to one of the products, both the 32 and 64 bit versions. Both work fine on two different development machines. One using Windows 10 and the other Windows 7. These were tested on a Windows 10 client and a windows 7 client. In both cases the programs ran, at first.
The software was deployed and then I started getting reports of the 64 bit starting and then just stopping. No errors. If the client PC already had an install it worked, just like on my test machine. However, if it was a fresh install then it would not work. Furthermore, if you rebooted the 64 bit machine the 64 bit version would stop working. Not only that, none of the other products I have would work either , even though it was months since they were installed. There are no problems on a Windows 7 machine at all. I did a build on the Windows 7 machine that hadn't been used in months and it made no difference. So the development machines are acting the same.
Now I traced the error to the first Windows form that opens in the software. Right at the InitializeComponent there is an access exception c0000005 in the module rtl160.BPL which is a delphi component. It occurs in the temporary folder c:\user\userid\appdata\local\temp. So it appears that somehow the wrong version of the delphi component or my code is all of a sudden trying to use temporary files in this folder.
So, my app is written in VS 2010, C#. I use libraries from Mitov.com that use a combination of a C# .NET wrapper and delphi code along with the Intel performance primitives.
In the 32 bit version, I distribute the dll's such as Mitov.SignalLab.dll which has all the delphi and intel performance primitives in the dll itself. On the 64 bit version, you distribute the the 64 bit dll's but you have to include the Intel DLL's as well. There is no reference anywhere to rtl160.bpl. So somehow, during release, and only it seems after Windows update this month, an rtl160.bpl is being used and it seems it is not the right one. This is included in windows driver cache(not sure what that is called...).
So, I'm kind of lost. If I could in some way, determine exactly which external files are being used on both the development machine and a client, perhaps a compare might show me something. But I have done this on the installed version and everything looks identical.
Can someone help? I did try a system restore on my client to before the windows update, but as the restore completed it reapplied the update!
This is really tough, since I could just get rid of the 64 bit version but I have a license manager which seems to not be able to determine the existence of the license when you open the 32 bit but had applied the license in the 64 bit. With 2 thousand users over 5 years I bet most have no idea where their license is.
Tom
Continue reading...
I have three products on the market. They are released as 64 bit version (with AnyCPU) and 32 bit versions. This 64 bit one is solely due it a specific driver not working correctly on the 32 bit code.
The products have been out for many years. This week, I released an update to one of the products, both the 32 and 64 bit versions. Both work fine on two different development machines. One using Windows 10 and the other Windows 7. These were tested on a Windows 10 client and a windows 7 client. In both cases the programs ran, at first.
The software was deployed and then I started getting reports of the 64 bit starting and then just stopping. No errors. If the client PC already had an install it worked, just like on my test machine. However, if it was a fresh install then it would not work. Furthermore, if you rebooted the 64 bit machine the 64 bit version would stop working. Not only that, none of the other products I have would work either , even though it was months since they were installed. There are no problems on a Windows 7 machine at all. I did a build on the Windows 7 machine that hadn't been used in months and it made no difference. So the development machines are acting the same.
Now I traced the error to the first Windows form that opens in the software. Right at the InitializeComponent there is an access exception c0000005 in the module rtl160.BPL which is a delphi component. It occurs in the temporary folder c:\user\userid\appdata\local\temp. So it appears that somehow the wrong version of the delphi component or my code is all of a sudden trying to use temporary files in this folder.
So, my app is written in VS 2010, C#. I use libraries from Mitov.com that use a combination of a C# .NET wrapper and delphi code along with the Intel performance primitives.
In the 32 bit version, I distribute the dll's such as Mitov.SignalLab.dll which has all the delphi and intel performance primitives in the dll itself. On the 64 bit version, you distribute the the 64 bit dll's but you have to include the Intel DLL's as well. There is no reference anywhere to rtl160.bpl. So somehow, during release, and only it seems after Windows update this month, an rtl160.bpl is being used and it seems it is not the right one. This is included in windows driver cache(not sure what that is called...).
So, I'm kind of lost. If I could in some way, determine exactly which external files are being used on both the development machine and a client, perhaps a compare might show me something. But I have done this on the installed version and everything looks identical.
Can someone help? I did try a system restore on my client to before the windows update, but as the restore completed it reapplied the update!
This is really tough, since I could just get rid of the 64 bit version but I have a license manager which seems to not be able to determine the existence of the license when you open the 32 bit but had applied the license in the 64 bit. With 2 thousand users over 5 years I bet most have no idea where their license is.
Tom
Continue reading...