DW has trouble hooking advapi32 and GDI32 on DDR3/4 systems.

[Goodmaneuver]

On faster RAM operating machines Dependency Walker has trouble hooking GDI32 and Advapi32. DW cannot read the export tables on Advapi32 and shows an incorrect CRC for GDI32. Identical hard drive/s in slower machines and all is OK. This phenomenon occurs on DDR3 & DDR4 machines.

Edited September 23, 2022 by Goodmaneuver

[schwups]

I would like to confirm this suspicion, but I have no DDR3 or DDR4 machine.  The "Module Dependency Tree" looks good for user32 on my DDR2 machine.

[Tripredacus]

You should test on RDRAM if you can since it is also not only faster than DDR2, but it was also around during the service life of 9x.

[Goodmaneuver]

While RDRAM can be a bit faster than DDR2, it depends on the machine. I benched MSI6339 1400MHz with Everest on WinXP and got a figure of 2000MB/s. Without going to too much trouble I am almost certain RDRAM speeds are not going to create the DW issue on WinME. It is probably more of a KernelEx issue than a purely OS one and the module load/offload timings get more critical with speed. With the introduction of IMAGEHELP into Kerxbases25v2 Win98SE worked but not WinME. Something is marginal here in that it is just working for Win98 I would estimate. To fix Kexbasen25v2 on ME all that was required was to force IMAGEHLP to use MSVCRT20. Other methods as discussed in Kext: DIY KernelEx extensions worked also but with IMAGEHLP using MSVCRT20, MSVCRT can use a KEX setting of Bases which is sufficient for all programs. It was a shame to see Jumper remove KernelEx 25 + tools version 2 as they must have had plans for debugging.

I have hot swap bays installed on ASUS MSA78LE and on ECVS KT890-A and this is a good speed difference comparison. Both motherboards have RAM set to slowest SPD settings. ASUS MSA78LE has DDR3-1300 (667MHz) and the ECS KT890-A can be seen in the picture. I have removed WinME off the Ryzen a few days ago for a number of reasons and one of them was this speed related issue although it was still working OK. RAM speed was greater than 50000MB/s on the Ryzen. Another thing is that after running the ECS then swapping drive to the ASUS this DW phenomenon does not occur for a while but does come back. Also Process Explorer on the faster ASUS does not show the Commit Charge correctly as it is indicating 2MB at 100% which is not true as can be seen in the ESC picture what the commit charge really is. I included a bench of Gigabyte MA78LM-S2 @ 3.6GHz with DDR2 and DW hooks modules OK there. I really cannot make comparison with the GA-MA78LM-S2 on commit charge as it is a different hard drive. It indicates 0% with a current value of 0 and a limit of 525948. All systems are using KernelEx24.

Edited September 21, 2022 by Goodmaneuver

[schwups]

Am I correct the problem occurs with following conditions:

Win ME

DDR3 or 4

KernelEx25 (v2) latest?

Kexbases:

EnumerateLoadedModules64 (ITO Stub)
StackWalk64 (ITO Stub)
SymGetLineFromAddr (ITO Stub)
SymGetSymFromAddr64 (ITO Stub)

These API's are supported by Imagehlp of ME, but not of Imagehlp of 98SE.

In the past I tested different versions of Imagehlp up to 6.1.7601.17514 (Win7SP1). Currently I use 5.1.2600.6198 (XP) on my main machine. But I also had used 5.0.2195.6613 (2K) and 4.0.1381.4 (98SE), but that doesn't matter here because I don't have a DDR3 or 4 machine.

[Goodmaneuver]

The topic now represents the issue correctly. The issue does not show when system is relatively new without much installed hence a small registry. The IMAGEHLP comments were unrelated to the topic. I just included it as I believe it is a loading timing issue when Kexbases 25v2 ( the first one and it used IMAGEHLP ) was introduce and I had found a solution. The best IMAGEHLP to use is from Longhorn 5270.

32 minutes ago, schwups said:

but that doesn't matter here because I don't have a DDR3 or 4 machine.

Perhaps someone else has come across this issue. There are other hooks that end up not hooking in my experience. One; NVIEW.dll; stopped working and that is why only one instance of Rundll32 loaded of which I mentioned in Kext: DIY KernelEx extensions :- I thought was an improvement but obviously not after finding out why.

[Tripredacus]

Another thing to check, ECC vs non-ECC.

[Goodmaneuver]

I know ECC SDRAM was not a problem with WinME but DDR3 ECC I do not have. Commit charge I believe it is PagingFile not FileCache as I have MaxPagingFileSize set to 409600 which correlates to the Process Explorer figure. and Vcache is set to 540000. I have just purchased some ECC non-registered DDR3 just in case it makes a difference and will need to wait a week before testing.

Edited September 22, 2022 by Goodmaneuver

[jumper]

I see no evidence this has anything to do with KernelEx. Please test with other configurations.

 

[Goodmaneuver]

I had already tried it on several different KEX24 builds and all have the hooking problem. Once setup on KEX24 I can not go backwards in KEX versions without ruining the system ( so far ). There is trouble with WinMerge as well in that doing a folder comparison it too does not read ADVAPI32 correctly but does say that they are the same once double clicked to compare the files. I have tested KEX25 on a relatively new installation and the DW hooking is OK as mentioned and have tested on KEX9 build that had come up straight from 4.5.2 and the DW hooking is OK and it has Classes size of 6800kB, System size of 7800kB and User 2000kB. The Process Explorer commit charge false reading between machines still occurs with the KEX9 build so I would think this is the RAM speed and Process Explorer at fault ( It would read the registry not system.ini ). The builds that have the DW hook issue have 1) Classes 9700kB System 9150kB User 3000kB. 2) Classes 8870kB System 9600KB User 3550kB 3) Classes 9600kB System 9080kB User 3530kB. ( the figures are rounded to drop last numeral )

I have taken Classes from 3) and System from1) and placed into KEX9 build. System.dat now is 10200 after merging back original And Classes is 9630. There is no DW hooking problem with KernelEx9 on the 4.2 GHz ASUS. Export tables are being read properly ( no :: voids etcetera ) and WinMerge reads Advapi32 as the same in folder view.

[jumper]

Insufficient testing. Disable KernelEx completely. Then report remaining issues.

 

[Goodmaneuver]

The main problem is if I upgrade before IE6 then it is OK but not OK when going back in KEX versions or taking away KEX2016 altogether after it is installed. If I upgrade after IE6 then I get the JS error. The JS error comes in real early as it happened once Kases8 is introduced. https://msfn.org/board/topic/173233-kernelex-45-core-updates-45201625/?do=findComment&comment=1208894 The full stop (.) before folder names also occurs when using Java base programs. A full stop before a folder name is not fully recognized as a folder in Win9x and the Java based program does not know how to write to the correct directory. I think it writes to the parent directory instead as well as adding a full stop. If Msvcrt is not given a minimum of Bases then some 3rd party applications do not know how to navigate the directories. An example of this is Miro Video Converter which uses Python.

1) Without Kex: The KEX9 drive has Office 2000 SP3 installed and taking out KEX and the Office helper works again. The build was good with no errors without KEX but now if I select search on the Browesui icon it goes for Office 2000 SP1 install MSI again but Office SP3 still works good. I think I messed it by updating a few system files but I do not know why.

2) If I use KernelEx now when selecting search I get an error in Kernel32 but was not the case before I messed around with it. I updated to KEX24 and no difference no extra problems but there is very little AppSettings in the registry apart from 4.5.2. This may be the difference and I did not want to place in CORE.ini of 24 as it will alter the 4.5.2 settings and this will make a difference too. Default settings :- DCFG1 will load VerSetConditionMask and VerifyVersioninfo if I use CORE24. The Kexbasen and Kexbases Dlls of 2016 wrap around 4.5.2 versions of both items and the original 4.5.2 CORE names are still functioning as they were in 4.5.2 even though CORE24 asks for a different definition name like BASE. The idea of having an operating system that operates without KernelEx defeats the purpose of this topic as KernelEx is not doing much and DW works with the faster system RAM then.

I did not really want help on this as I was pointing this phenomenon out and it can happen and will in my case. I have updated the topic to reflect the new findings.

I would like help though Jumper, I would like WinHttp.dll from WinXP to register. It is preventing me from registering other modules that programs will use. Can you see if you can register it? I forgot about ReactOS and WinHttp works OK from ROS.

Edited September 24, 2022 by Goodmaneuver

[Goodmaneuver]

I am not sure that the first paragraph last post is correct about IE6 and I may have to delete it. There is an issue but it could be that 4.5.2 needs to be installed after IE6. This is what my MSFN shortcut seems to indicate.

[Goodmaneuver]

I thought I was purchasing the RAM locally but is was overseas and just arrived a few days ago. The funny thing is that I already had ECC unbuffered RAM installed. The good part is the newly purchased RAM works. There was no change in the Process Explorer commit charge reading. The DW issue was marginal in the first place on the DDR3 machine and seems to be non-reoccurring once I had fixed several registry errors along with addressing some well used system files so that they are referencing internally %WinDir%\system instead of Windows\System32 etcetera. I have also worked on KernelEx and it now has less errors in my Kstubs (no == or=>=> or duplications). Only a couple of redirects untested. I am thinking my Kstub errors may have been a main contributor to  the DW issue. GDI32 now has correct CRC. The registry errors were checked using RegDllView and most directories that were wrong were corrected.

On 9/23/2022 at 11:52 AM, jumper said:

Insufficient testing. Disable KernelEx completely. Then report remaining issues.

The only issue without trying to run any KernelEx dependent programs was that on opening the root directory of C: I got the scripting error in Sysroot.htt.

[Goodmaneuver]

DW errors have returned after updating a module its seems but it is not the modules fault. I am not ready to comment further.

Edited November 10, 2022 by Goodmaneuver