Since the latest Windows update (creators-update, winver gives 1703, build 15063.483) we have problems with VBScript accessing COM objects. It just seems to consume memory until memory exceeds.
We already have checked our sources and made it to just one simple vbs file that uses the FileSystemObject.
Look at this simple script file:
Dim fso, folder
Set fso = CreateObject("Scripting.FileSystemObject")
If Not fso Is Nothing Then
Do
Set folder = Nothing
Set folder = fso.GetFolder("C:\Users")
Loop
Set folder = Nothing
Set fso = Nothing
End If
It does just nothing but hanging in that loop, but if O look at the Task Manager I see the process wscript.exe consuming memory.
This doen only happen on Windows 10 systems with the creators update installed.
Any hints whats going wrong? Maybe a bug anywhere in the VBScript engine?
Finally Microsoft have a solution in a general release of Windows 10.
The Windows 10 Fall Creators Update (OS Version 1709 Build 16299.15) is now available and fixes this issue.
This is fixed in Version 1703 (OS Build 16241.1001) obtained via Windows Insider Program - Fast Ring. I assume this will eventually be rolled out in a generally available build.
Related
Update: It turned out that there was something with installing Delphi 10.4 CE that broke my app (thanks, DelphiCoder!); specifically, it was something in the Windows Registry that was broken. After using ProcessMonitor to ensure no Delphi 10.4 (aka 21.0) was being invoked, I ended up cleaning out the registry of all 10.4 references, rebuilding completely (not clear if this was needed or not), and lo and behold, it works again! I'm adding this update in case someone in a similar situation finds this question - remember to back up your registry first and be careful!
Original Post: I created several DLLs with Matlab Compiler 10 years ago, with C wrappers, to make them available with Delphi. Once I got them working, they always worked - until today! The code in the C wrapper initialization function in question is in the code box below; the "Could not initialize library" is printed to the console when I run my Delphi app.
mclmcrInitialize();
if (!mclInitializeApplication(NULL, 0)) {
fprintf(stderr, "Could not initialize application\n");
}
if (!libMyDllInitialize()) {
fprintf(stderr, "Could not initialize library\n");
}
The problem is that this has never happened before, over all the probably 10 years since we first wrote these! My machine has the correct version of the 32-bit 2021a MCR installed, as it has for several years; I've installed this on numerous machines from Windows XP up to Windows 10, The DLLs were last built 5 - 7 years ago; anyway, I don't have access to the Matlab compiler anymore. The only thing that has changed is my app, but not anywhere near where this DLL initialization code is called; also, when the problem first happened, my app was working, then didn't -without any changes. Finally, I went back a few days and rebuilt my app, and it still fails.
So I am really stuck, and need some advanced help in debugging DLL startup issues on Windows. I tried looking in the Windows Event Logger, but nothing appears to show up there. Logs to check? A setting in the Registry that somehow got hosed? Wrong phase of the moon? How does one debug loading/initializing a formerly working DLL when forced to treat it as a black box? Help!
How does one debug loading/initializing a formerly working DLL [...]?
I think there is no definitive answer to your question.
This is how we have gone about debugging the loading/initializing of DLLs and applications and may help you:
We regularly work with systems where we have no source code for the DLLs (and often we don't have any source code for the applications either). We experience DLL conflicts quite regularly. When testing why applications don't start as expected we have found the use of Sysinternal's Process Monitor by Mark Russinovich invaluable.
This will show you system level activity. You can filter for your process and then you will see all file, registry, thread and network activity (although thread and network are quite limited). If the DLL has dependencies then the system tries to find those and so you will be able to discover all dependent DLLs and COM interfaces (by seeing the registry lookups for that interface) that it's looking for. Process Monitor will show if the resource is not found or if access is denied.
Slightly more difficult to discover is if one of the dependencies exists but the export table has changed (so the functions have different signatures or export ordinals). There are ways to check that (by looking at the export and import tables) but generally (if you have access to a working environment) it's enough to check the filesize, timestamp (and the VERSIONINFO resource if there is one) between DLLs.
I previously had many C++ .exe programs (developed with C++ Builder XE7) running as scheduled tasks in a Windows 2008 R2 Datacenter server. These tasks were being run by the SYSTEM account and I never had any issues with them before.
I recently imported these tasks to a new Windows 2019 Datacenter server and set these tasks up in the Task Scheduler. The same SYSTEM account is being used to run the tasks, but with the updated Windows Server, these tasks now give me a run result of 0xC0000142.
Most of the resources I found online say to increase the desktop heap size in the registry editor - I have done this multiple times and restarted the server after each increase, but I was still getting the same results with this method so I reset the desktop heap size back to the original value.
I also thought it had to do with missing C++ redistributables - the new server only had redistributables from 2015-2019, while the 2008 R2 server had these along with redistributables from 2013 and 2008. So I installed these extra redistributables but I still got the same result.
I have tried manually recreating the tasks, I tried running the tasks with different domain admin accounts, also played around with the "run only when user is logged in/run whether user is logged in or not" setting. All of these led to the same 0xC0000142 error.
Also, there were no errors being shown in Windows Task Scheduler history or in the Event Viewer.
Any extra tips/guidance would be much appreciated!
EDIT:
Here is a snippet of the filtered Process Monitor logs leading up to the exit code and task failure.
EDIT 2: It's been over a month now and still running into these problems. I have upgraded C++ Builder to 10.4, moved my old code to the new IDE, and re-linked all the packages/include paths/library paths. I also took my original .exe I was working with and split it up into multiple tasks with multiple .exe files - now most of these split tasks are running, but some still give the 0xC0000142 code. I also tried to use this tool from GitHub - Dependencies App - to attempt to find out what exact DLL is failing, but it just points me to some core Windows system DLLs (api-ms-win-....dll, ext-ms-win-....dll). I feel this output is misleading, does anyone know of any better tools to determine missing DLLs?
I figured out the issue to my problem. In my case, the program with the 0xC0000142 error was using WININET. Near the top of my cpp file, I had #pragma link "WININET.LIB". The WININET library is not supported in Windows Server 2019, so attempting to use it results in failed initialization of some system DLLs. By removing the #pragma link statement and replacing/removing unnecessary WININET functions in my code, it allowed my program to run on Windows Server 2019.
This is a weird one. I've now installed Delphi 5, updated to service pack 1, on my brand new Windows 7 64-bit machine. It seems to function well enough, but when I start it up an error message comes up telling me that the system cannot rename Delphi32.$$$ to Delphi32.dro. I thought "Okay" and went in to rename it manually, only to find that there was no Delphi32.$$$ but there, large as life, was a Delphi32.dro ...
I'm logged on to an administrator-level account, so I figure it isn't a permissions issue.
I'm willing to live with this slight annoyance, but I am worried that it is symptomatic of some deeper problem.
Has anyone else encountered this?
This is a user permissions issue.
Even running as an administrative user, Windows 7 puts some limits on where applications can write. C:\Program Files, (AKA %PROGRAMFILES%) is off-limits except to applications explicitly started using "Run as Administrator", even if you're running under an account with Admin privileges.
More recent versions of Delphi properly handle running from the restricted folders, but D5 was outdated long before Win7 was released and therefore does all sorts of things that aren't proper now. It writes to its own Bin and Lib folders, for instance, and stores the default Projects folder for your own projects there as well.
The easiest solution is to uninstall Delphi 5, and reinstall in a location outside the %PROGRAMFILES% directory structure, such as C:\Delphi5 or C:\Borland\Delphi5. Installing in a different root level folder resolves these issues.
Actually, the easiest solution is to upgrade to a more recent Delphi version, but I'll presume that isn't an option. :-)
This might also help with Delphi 5:
http://blog.dummzeuch.de/2013/11/11/delphi-6-on-windows-8-1/
Ken White's Answer sums it up nicely.
Installing Delphi in a folder other than "Program Files" can threaten and infect Delphi files, and malware can easily infect your Delphi files
(this is a serious threat).
My suggestion is to install a sandbox (or a program virtualization) such as Sandboxie-Plus and Run Delphi from it, you can force Delphi to always run from the sandbox, just be careful your project files are stored inside the sandbox, so you have to manually move them out of the sandbox (for when you want to publish it)
We bought Delphi XE to slowly upgrade from Delphi 6.
Delphi 6 is well working in Win7/X64.
I installed two virtual machines to test it (I planned three of them, but Virtual PC is not supports X64 guest OS).
1.) Sun VirtualBox 4.x
2.) VMWARE player latest
The guest OS is Win7/X64. Latest SP's, packs are installed.
I set local "area" settings to "english-usa".
I started the installer as admin.
The phenomenon is:
The InstallAware is starting, the progress bar is access the 100%.
After this a new InstallAware Window is starting, but later it disappeared.
Then nothing happens. Sometimes the Windows say (dialog) that setup is not working, will I reinstall it?
The event log is not containing information about the problem.
I tried to starting "setup.exe" directly with "as admin", but the result is same.
I tried to find the real setup files in "Local Settings/Temp", and starting it directly as admin, but I got same result.
So I'm very disappointment, and puzzled... We bought something that is not installable.
May I can install the XE into VPC/XP Mode; but I'm sure the somebody CAN install this software in Win7/X64... :-(
Can anybody help me, how to continue the installation?
How to "debug"?
Thanks for your help:
dd
It might be a problem with your virtual machine, i have myself issues with VirtualBox.
You also should double check if you dont have a corrupted Iso. Try to download it again to see it works.
I work in a software house that have at least 30 people working with Delphi XE on their Windows 7 machines. None of them ever reported a installation crash.
Another good question: are you executing the setup.exe as administrator?
The solution was if I copy the zip file directly into VM (not download it), and I must set ALL AREA FLAGS to USA.
The language, the area, the format settings - all things!
Then the installer simply working...
Thank you for your help!
Regards:
dd
After many months of postponing it, this week, I finally started using a new Windows 7 Professional PC for actual development (which is 90% still done in Delphi 7 with some of these programs still using the Borland IDAPI to access Paradox files). The previous development pc was still an XP-one.
Every thing works except for one thing: somehow the settings of the IDAPI and BdeAdmin configuration files are messed up or they are read/written in different locations. To be more precise, it looks like two configuration files are active.
It must have something to do with rights or settings being read/written in the wrong folder or registry setting, but after searching for it for a couple of hours, I give up.
Anyone had any problems with this, before ? And if so, hopefully, has any one solved this problem ?
Thx for any thoughts/solutions ...
My guess is it has something to do with the fact that Vista and Windows 7 don't allow programs to change files under the C:\Program Files folder. They create a copy of those changed files in a virtual store, the process is known as virtualization. The copies end up in the hidden appdata folder of the user account and can be found in the Local\VirtualStore\Program Files folder. The structure in that folder reflects the one in the actual Program Files folder.
Programs that access their files in the Program Files folder using a "hardcoded" path, will always get the original - unchanged - file contents.
Solution: running the apps in a virtual XP system or upgrading the apps is probably your best bet.
You could try to run the apps elevated. That is: right click them and choose Run as Administrator. Please note that it isn't enough to be logged in as an administrator. Even administrators run all processes unelevated by default. Instead of right-clicking, you can also create a shortcut and set the Run as administrator for the shortcut - the checkbox for this is on the compatibility tab of the properties dialog. No guarantees though that this will alleviate the problem.
Since IIRC D7 setup allows you to configure paths in multiple ways, maybe simply do a reinstall outside "program files"?
Afaik this solves several vista/w7 problems.