Jump to content

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


Goodmaneuver

Recommended Posts

I am please to say that I have fixed most of the issues discussed here. The GDI32 CRC error and ADVAPI32 export table errors with DW have been fixed with the Kstub entry for [ADVAPI32.DLL]
QueryServiceConfig2W=>RADMIN32:QueryServiceConfigW

I did not want to send QueryServiceConfigW API back to ADVAPI32 just in case both QueryServiceConfig2W and QueryServiceConfigW were called at once.

The 100% Commit Charge still exists in Process explorer. The testing was done on ASUS MSA78LE.

Link to comment
Share on other sites


It was early days with this and one other thing that has to be ensured. If redirecting to RADMIN32 from KERNEL32 then the redirects have to be redirected to a renamed RADMIN32 otherwise these DW errors come back. The MEDAL idea is discussed in DIY KernelEx extensions.

I think this statement is correct but I was confused when a module would not pass the register test which prompted me to alter this post. I might as well print the register results from DW. KernelEx stopped working while registering.

MSXML3_DW.png

Edited by Goodmaneuver
Purple text
Link to comment
Share on other sites

3 hours ago, jumper said:

Does the Kstub log show that QueryServiceConfig2W is actually being called?

The log file for Kstub01 has not updated since 8th January 23 so this is suspect. It is 64kB in size. The other ones have updated 13th January :- today.

 

Link to comment
Share on other sites

Great! The log file is an .ini file and 64KB means it's full. Use SORT in a DOS box, edit out the duplicates, and post the results (or just compress and attach). That will show me the highest priority APIs I should be looking at.

Then delete the log file and let it start filling again.

 

Link to comment
Share on other sites

I deleted many lines in Ksub01 at the top. They were only locale name to LCID and LCID to locale name functions. I then opened several programs but no new different APIs were listed in Kstubs. When you said we have to find definitions, is that really true, or can we use Kstubs for redirection like I am doing.

KSTUBS.zip

Edited by Goodmaneuver
typo
Link to comment
Share on other sites

https://msfn.org/board/topic/183930-dw-has-trouble-hooking-advapi32-and-gdi32-on-ddr34-systems-with-many-kernelex2016-app-settings/?do=findComment&comment=1235306

This link is to the above post of mine. It turns out that it is quite specific I accidentally made a duplicate of [KERNEL32] RtlCaptureContext=>MEDLL: (MEDLL is my renamed RADMIN32. The MEDAL option). It is necessary to do this to stop the DW ADVAPI32 error. In [MEDLL] I have RtlCaptureContext=>KERNEL32:GetTreadContext. It is not necessary to have the the [MEDLL] redirect there to get the ADVAPI32 error to go away though. I tried for hours to see if ADVAPI32 error would go away but it did not. It went away when I placed in the duplicate of RtlCaptureContext redirected to MEDLL. It went away straight away after reboot. The GDI32 CRC read error is unrelated though and still occurring. The original fix did both fixes on 2 different builds at that time. Since then the build I am working on is a bit more complex.

Link to comment
Share on other sites

On 1/13/2023 at 4:16 AM, Goodmaneuver said:

KernelEx stopped working while registering.

Actually working more than ever. It tells you exactly what it could fix if you had ApiLog running in the background instead of just letting the load fail silently.

Looking at the log files now.

 

Link to comment
Share on other sites

4 hours ago, jumper said:

Looking at the log files now

It did not matter about that module, it was more of an experiment. It was MSXML from WIN8 and I am using latest WIN7 MSXML which registers no problems. I will send in a failure of an unexpectancy soon as I am working on the concept that because Verify Version needed GetCharABCWidthsI=kexbasen.0 added then perhaps kexbasen.0 and kexbases.0 is not default and will need to be added throughout where applicable. It might be a while though. I will do my best.

.

Link to comment
Share on other sites

GetCharABCWidthsI was inherited from DCFG1 so it makes sense that GetCharABCWidthsI=kexbasen.0 needed to be added; I forgot again. If not added it made the green KEX initiating error in DW log when GetCharABCWidthsI was called and was missing. The green errors means that KEX was not working/initiating. It depends on the order of std,kexbasen,kexbases,kstub01,kstub02,kstub03,kstub04 what DW green initiating error comes first in the DW log.

Edited by Goodmaneuver
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...