Goodmaneuver Posted January 12, 2023 Author Posted January 12, 2023 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.
jumper Posted January 13, 2023 Posted January 13, 2023 Does the Kstub log show that QueryServiceConfig2W is actually being called?
Goodmaneuver Posted January 13, 2023 Author Posted January 13, 2023 (edited) 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. Edited January 13, 2023 by Goodmaneuver Purple text
Goodmaneuver Posted January 13, 2023 Author Posted January 13, 2023 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.
jumper Posted January 13, 2023 Posted January 13, 2023 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.
Goodmaneuver Posted January 14, 2023 Author Posted January 14, 2023 (edited) 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 January 14, 2023 by Goodmaneuver typo
Goodmaneuver Posted January 14, 2023 Author Posted January 14, 2023 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.
Goodmaneuver Posted January 14, 2023 Author Posted January 14, 2023 After mentioning all this, if the sequence of the std,kexbasen,kexbases,kstub01,kstub02,kstub03,kstub04 in CORE.ini is altered then ADVAPI32 error returns and won't be good again if placing CORE.ini back as it was.
jumper Posted January 14, 2023 Posted January 14, 2023 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.
Goodmaneuver Posted January 15, 2023 Author Posted January 15, 2023 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. .
Goodmaneuver Posted January 15, 2023 Author Posted January 15, 2023 (edited) 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 January 15, 2023 by Goodmaneuver
jumper Posted January 15, 2023 Posted January 15, 2023 What is: 9 hours ago, Goodmaneuver said: Verify Version
Goodmaneuver Posted January 15, 2023 Author Posted January 15, 2023 Verify Version is probably not worded real well but it was discussed in Kext: DIY KernelEx extensions where I first posted this info about DW but it was shifted here to a new topic.
jumper Posted January 16, 2023 Posted January 16, 2023 Mentioned, but never explained. So what is it?
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now