Goodmaneuver

FlameOnion said it would not boot into safe mode with SATA so if USB boots into safe mode then it uses vcache. To tell this you can boot up with step-by-step confirmation with WinME and it will ask whether to load all Windows drivers. If selecting 'no' it will ask whether to override standard drivers and at the bottom of the list is vcache. Vcache cannot be avoided it seems and needs to load when starting in safe mode.

The way I see it is that it works on USB so there is not problem with vcache. There are no access timing settings for SATA as FlameOnion would have said I think. To check, select the HDD itself in BIOS and there might/should be a Multi-Sector Transfer option, A PIO Mode, DMA mode, Smart Monitoring and a 32bit Data Transfer option. I usually select PIO Mode either 0 or 1 and DMA SWDMA0 or up to MWDMA2. I select the lowest first and then you can test drive speed later. Even on the lowest settings the HDD can be going flat out and will not go any faster. The actual HDD speed capability with the settings is determined with the BIOS and it is not a universal standard. Speeds can be tested on another OS. The SATA is driven off the PCI I would think and devices like USB are also driven from PCI. They quite often are jostling each other for bandwidth and PCI bus has to be in excellent condition for 16bit drivers it seems. If this board is new then perhaps exercise it with a different OS first. Do not push the HDD any faster than it can go as the time to get data to and fro will get shorter with higher speed settings and not recommended to run with the BIOS test setting it chose, but every BIOS is different. FlameOnion disabled as many devices as possible before testing on USB so they did the right thing there.

Just to be clear, it does not appear that MSVCRT is supposed to call InitializeCriticalSectionAndSpinCount as seen with the same settings for DW and MPlayer2 and MSVCRT set disabled picture. DW is set BaseN and MPlayer2 set in follower mode. This is the same as before when posting DW log. Profiling with DW is working with MSVCRT set disabled. Other programs will be affected as well so MSVCRT must be disabled. To Jumpers credit there are no red errors and no function calls in Depends when Depends is set on DCFG1 or in follower mode. Explorer in advanced build of mine that I got going on KEX25 is set DCFG1. There are no calls in Depends showing except DllMain the modules and returning 1. Oleaut32 should not call SetCriticalSpinCount when using correct KernelEx modes nor should UnhandledExeptionFilter be called.

@jumper; I made a mistake in registry I believe as evidence seems that way. There was no problem having MSVCRT set Win2000std as far as adding devices. The devices would have all installed and the next module to load probably caused KernelEx.dll to not be able to start. I had *\MSVC*.DLL set BASEN when I looked, sorry about that.

@jumper Note Well : - This quote is correct but DW does not profile when it is set itself to BaseN nor Win2000 std for examples and that is why MSVCRT needs to be set disabled. Investigating : -Testing with MSVCRT set to Win2000 std, DW itself set on Win2000 std causes huge problems so I set DW BaseN for testing. This may emulate the Base enhancement errors. The results are not helpful as DW can not hook ImageHlp. Help :- If wanting MSVCRT to run in BASE then ImageHlp can be made use PerlCrt which is almost the same as Pncrt and probably Pncrt vs 5 and set PerlCrt to disabled. That works to boot but Dependency Walker still has trouble with MSVCRT left in BASE when profiling with Depends set to other modes. The end log results with DW set to BaseN and profiling MPlayer2.exe, hope it helps. 00:00:00.361: DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\tools\bench & diag\dependency walker\DEPENDS.DLL" called by thread 1. 00:00:00.368: DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\tools\bench & diag\dependency walker\DEPENDS.DLL" returned 1 (0x1) by thread 1. 00:00:01.848: DllMain(0x7D000000, DLL_PROCESS_ATTACH, 0x00000001) in "c:\me\system\MSVCRT.DLL" called by thread 1. 00:00:01.852: GetProcAddress(0xBFF60000 [c:\me\system\KERNEL32.DLL], "InitializeCriticalSectionAndSpinCount") called from "c:\me\system\MSVCRT.DLL" at address 0x7D0077FF and returned 0x84D79E08 by thread 1. 00:00:01.857: DllMain(0x7D000000, DLL_PROCESS_ATTACH, 0x00000001) in "c:\me\system\MSVCRT.DLL" returned 0 (0x0) by thread 1. 00:00:01.890: Exited "c:\program files\windows media player\MPLAYER2.EXE" (process 0xFFFA66AD) with code -1 (0xFFFFFFFF) by thread 1.

If you are keen you could buy an add on card like a SCSI card. Once the HDD is formatted and OS files are on the SCSI HDD them the SCSI card runs from BIOS so really does not need drivers for the OS. File system restraints still apply. The other alternative is if it can boot to USB but this could be tricky but I bought a USB2 card that worked without drivers installed as at first the bios controls it I estimate. It would be easy to test if boot to USB was a function in BIOS as just get a USB external disk or memory stick with the OS on it and see what happens. The vcache is within VMM32 or external with rLoew's I think but if looking at previous load and is taking file system I would say that the error would say cannot install the next item. See if Boot Logging is writing to the HDD.

Well if you mean other files and before KEX25 then there was no problems really with BASE setting and only has occurred since KEX24. With Kexbases25 everything that needs Msvcrt seems to not work with Msvcrt on BASE setting and rejects sharply. It is almost impossible to Ctr+Alt+Del interrupt the processing on the new build. I did it once but then you can not run a new program as the Rundll32 has problems :- The Rundll32 fault. Schwups don't forget to say BASE does not work BaseSN may imply that Base enhancements doesn't work but it is a little different. Dependency Walker profiles good with Msvcrt Windows 2000 Std heap settings and also Base std heap but not if Depends is set to a mode setting itself like BaseN or Win2Kstd.

No; with my advanced build and new build Base does not allow boot. BaseS works but BaseN does not. I vouch for Schwups that BASE standard heap works and I hope that he can vouch for me that Windows 2000 standard heap also works. MSVCR90 will need more than base to work, NT40, but 6,7,8 can be operated disabled. Do you mean 0x80000000 or 0x00000080? I have not seen 0x80000000 before.

New discovery: if the Core.ini string for kstub is kstub823 then Kstubs will still work if the kstub.ini and kstub.dll are named kstub824. It seems the OS looks at the first 7 characters on a new install. This can be altered though in the setup; if you are going to alter INFs then this 7 character sighting can be changed but SFNs right throughout as well need changing. Must be changed within the install CABs.

WinME conclusion so far. It might be best to rebuild again with KEX25 as everything seems to work out alright if following directions above. If trying to update an advanced build it probably will not work out too well if KEX was installed after IE6. For instance I got it all to work up until Kstubs. Kstub823 works but not really with Msvcrt of Win2K3 on my build which is the only Msvcrt version that worked. When trying Kstub824 the scripting error came in and when removing Kstubs824 there was no scripting error. This error showed as unspecified 30 as explained in Core updates topic top of page 51. It also might be best to have KernelEx set disabled from the install as Jumper requested. I agree with tyukok about the leak idea. What ever the reason now with KEX25 going from Mozilla to PotPlayer does not interfere with DXVA playback. It depends on how much browsing is done and then it still knocks out anti-aliasing that is inherent with older nVidia drivers. (drivers modern for WinME though)

Did you try installing on a smaller hard drive. You seem to know what your doing but it could be a hard drive issue. Can you lower the access timings in BIOS?

Preamble : - The advanced build that worked has Msvcrt vs from Win2K3SP2 as Msvcrt. Method to use this file is explained by myself in other posts. If I changed this version it would not work. I tried 6.1.9848 and Msvcr70 and Msvcr80 vs 8.0.40209.38. All should work without problems. So this is one of the necessary requirements for my advanced build. The Fix : - Most problems and especially the Dependency Walker issue can be fixed by removing *\MSVC*.DLL in Configs section and have MSVCRT*.DLL, MSVCR8*.DLL and MSVCR7*.DLL disabled. Flags section for example for MSVCRT and variants: *\MSVCRT*.DLL=1 Double Word value, then reboot. Dependency Walker then works good. Other MS visual common run-times may need a separate setting but in follower mode seems to be OK for now. Black Wing Cat's wrapper which I have named MSVCRS will still load disabled but not in Safe Mode so it is set disabled too. Method to use this file is explained by myself in other posts.

If you are using Win98 have you tried limited memory access to 1GB by adding MaxPhysPage=40000 in system.ini and under [vcache] in system.ini have you tried limiting vcache to say MaxFileCache=344064. In case the expanded memory has got something to do with it then you could try SysVMEMSLimit=2048. see http://conradshome.com/win31/83435-6.php I would try a smaller RAM stick, one that is the same size or smaller than the h87 total equivalency if you can.

There still could be too much RAM, did you do this; from rLoew's comments. "If you have more than 2.75GB of available RAM in your Computer, Programs that use XMS Memory may exhaust the default supply of Handles offered by HIMEM.SYS. Add the following line to your CONFIG.SYS file before any program that might use XMS Memory to prevent this problem: DEVICE=<path>\HIMEM.SYS /NUMHANDLES=64" I do not know otherwise except that the hardware accesses RAM differently as technology has evolved: - controlled by hardware so should be OK.

Did the h87 have that same amount of RAM? What does removing the 1060 mean?

I have just got one of my recent builds working with KEX25. What I discovered was that the original SessionManager KnownDLLs from a fresh OS install need to be there with KEX25. I took them from the working KEX25. If you look at my KEX25 picture it will show 65 of them which were only System files which pointed to themselves. What I did was to take my working new build SessionManager 32bit KnownDLLs and export them. I then booted up an advanced build in safe mode placed in the KEX25 modules except Core.ini and used the Core.ini in my last post then merged the new install SessionManager KnownDlls. Then I merged the AppSettings.zip I uploaded. This got an advanced build working and no scripting error occurred and should not happen just on a merge. The *\MSVC* then can be changed to suit a 2K like mode in the AppSettings and this includes DCFG1 in later KEX as I mentioned some while back and duplicates removed. If after removing duplicates and upon reboot problem returns, the merge procedure needs repeating again in Safe Mode and register KexCom again in Safe Mode. That is what I did as I removed *\MFC*U instead of removing *\MFC* but I did not do this intentional mistake second time. DCFG1 does not work if the application stipulates that a 2K or higher operating system is required though. Thank you for making changes to Kstub Jumper. To make things easier I will upload new requirements soon.

@jumper; I have all modules working with WinMe now. I have fiddled with Core.i25 and what makes it work I think is the order in which the first few mode listings order is set. See https://msfn.org/board/topic/157173-kext-diy-kernelex-extensions/?do=findComment&comment=1209284

I have all modules working as Jumper wanted as far as functionality is concerned. In the process of fiddling with Corei25 I have considered a first 7 character sighting with SFN in the registry but this is probably not a problem. I believe it helps changing the order of the first few modes around. Uploaded Core.ini_2 in zip. WinME looks at the most significant bit in sorting order so 12 is sorted before 2 for example. If sorting numerals there should be zeros in front of the numbers to match the number of significant bits of the highest number. CORE_2.zip

As can be seen in the Ktree11 picture, Unicows is a KnownDLL. If Unicows is used this way there will also be a need of a copy of it in the System folder if the KernelEx folder is not a mapped environmental directory. This is because if a program is KEX disabled or calls Unicows as an implicit then it will find Unicows in the System folder. Same goes with any other modules as a KernelEx KnownDlls. I have had both Unicows actively loaded in both directories at the same time. It is not necessary to have Unicows as a KernelEx KnownDll and I will probably remove it soon. The method of getting KEX25 to work works from a complete 4.5.2 install so the other KernelEx KnownDlls have been installed and the install method worked. The SFC control panel looks like picture on a new build but looked different on old build and was disabled.

Preamble : -@schwups @jumper and others; it works on builds that have had put on KernelEx prior to IE6. So do not use a good build as the scripting error could happen as described on top of page 51 in core updates topic or it does not work or not work fully. The *\MSVC* should be = NT2K not NOHEAP. See I did not change anything from my 4.5.2 build. I did not update the SP VXD's either this time in the VMM32 folder before the first machine restart but I believe if you do then it will not make any difference to the result as I have tested the reproduced Vmm32.xvd of updated versions and still OK. All VIA drivers and SYS files in System32\Drivers were copied over before reboot. You can update the Install cabs if you want as well, WinME is not fussy about that if copied onto the hard drive. The Quadro FX5500 went straight on after a standard PCI graphics driver. I know this as the screen refreshed before asking for the 82.69 files and upon reboot the standard PCI graphics driver was there not functioning so gets removed. You need to be able to access any modules that the setup may ask for that you may have forgotten. Skip any files that are in the System32\Drivers section that setup has trouble with, the files are already there. Vredir.vxd update is the one to indicate network drive size correctly residing in the system folder. Files need replacing in the SFP\Archive folder and the system just like an NT system. I have on one build SFCPL.cpl from 51.2451.1, SFC.dll from XP 2.2600.3264 and SFC_OS.dll from ROS 2017 and it brings up the Control Panel for SFC and indicates that it is turned off on that build but have not investigated it any further just yet. Findings for KEX25 : - The new discoveries with KEX 25 is that it kills Dependency Walker from accessing Depends.dll export table; Depends.dll memory location 998. This only happen before if Depends was operated under a higher mode setting above about BASE. I cannot be more specific but WIN2000D definitely would create that Depends error in KEX24 and prior KEX's (precisely started when is ?). Depends and Process Walker cannot profile anything anymore. The programs I have used and OK so far are WinMerge 2.14 Unicode, CometBird9 and KMPlayer4.06. All programs installed fully under KEX25 with Core.ini20. These so far are InstMsiA2, 7-Zip 9.20, Internet Explorer up to Q982381, Visual C++2005 redist, Visual C++2008 redist 9.030729.17, NVIDIA PhysX (Legacy), Paragon NTFS for Win98 and DirectX 9C official 2007. NVidia display panel indicates with this install; Processor NVIDIA (Unknown); Memory 1024MB; ForceWare version 82.69 and DirectX9.0 or better. System file protection can be a problem though and the files may need to be copied from the SFP\Archive folder to system folder for some IE6 files I found. Obviously off line for this. Perhaps MDIE6CU was unofficial but does a good job of the install apart from what was discussed last sentence. The Debug Button : - To get the Debug button on the error window I had installed something and the settings reside in the System part of the registry. I believe that Visual Studio 6.0 Enterprise (6.00.8168) has this feature but it may say there is nothing that requires it so install visual-c-sharp-2005-express-edition-es-en first. That might work. I have them both installed on latter builds. Copy the full name of the programs and do a Google search. It is advisable to have it available to load on restart for VS6 (on CD hardware for example) as it may want to restart the machine. As a precaution then, have a copy of system modules that were upgrades from original ME modules. The Symbols may not be available from Microsoft so a debugger of your choice can be used instead.

I have all K25 modules working bar Core.ini. I have found that the latest Core.ini causes problems and does not work. I am using Core.ini20. I have up loaded the CORE.ini to use and the AppSettings in reg format. What to do to get KEX25 to work : - Boot into Safe Mode then place KEX25 modules in your KernelEx folder and the Core.ini I uploaded. Take the uploaded AppSettings Reg file and merge it then register Kexcom.dll18 while still in Safe Mode of-course. You can have a look at the Reg file but do not alter it in any way otherwise it probably will not work. Do not alter the Core.ini either it is slightly different to 20i and can be altered to add Kexstub824 later. Changes to AppSettings mainly are more multi-use system modules disabled. Once the AppSettings.reg is merged you can delete any double-ups for example; *\NV*.DLL being equivalent to C:\WINDOWS\NVOPENGL.DLL; by doing a search for \NV and search *NV if you did some that way and the modules name starts with NV, in this case. I do not think removing duplicates will be essential at first but if not done in Safe Mode then it must be done when booted into the OS properly. Most nVidia modules start with NV so I would not advise to do *NV*.DLL as *\NV*.DLL focuses the module target better. If you want you can start a fresh, just delete the AppSettings key only, of the registry, and register the upload; it will suffice for booting if applications boot through run-time without the need for a special KEX mode setting. If the full boot stalls, Ctrl+ Alt+ Del and see what is making the stall; it would be not responding. This may take a few seconds as it will be going 100% CPU usually. On first time boot Msgsrv32 may be stalling so terminate it. Sheet.dll19 can be registered when fully booted into the OS. I have made Msgsrv32 disabled even though it is 16bit in the chance that KernelEx is invoked by another App like Volumouse but this may not work. As far as going too far, perhaps some operating modules do not need disabling but there are only a few more. I was lucky that I disabled them at the time with the build I was working on with 4.5.2. I did not disable Cmdninst.exe and Runonce.exe but I think they should be. AppSettings.reg has 4.5.2 mode settings only, so it is compatible with 4.5.2. AppSettings.zip

Even though Msgsrv32 is 16bit, KEX can be in use as seen in KEX24 picture. The top image is of the newer install with KEX25 prior to Volumouse and the bottom one is from a different build with KEX24. I have looked on a build with KEX12 and KEX is in use on Msgsrv32 also. It is because Volumouse (Vlmshlp) is hooking Msgsrv32 and dragging along KernelEx. Mmtask.tsk on KEX24 build is from an early Whistler release and is 32bit. EDIT mistake. These 2 builds of mine have System Monitor CPU usage of a certain percentage as can be seen. I think is accurate now and is something to do with 16bit and the registry. Some people have dismissed this as a false reading but I have had it zero on one build and that build had server buffers at zero at the time. It is to be noted that the registry is running top down in Win9x and bottom up in WinXP I think, from my memory of such. This is likened to Ntdll linking directly to Kernel32 and is loaded in Win9x where as NT OS versions Kernel32 loads calling Ntdll.

To install RP9 on WinME. turn off system restore at least temporarily. If stopsfp.exe is allowed to run while not in safe mode it most likely will stall the machine if system restore is running due to state manager and system restore manager. Install RP9 in safe mode and choose the icon set and or theme you would like before rebooting. See if wininit.ini has any tasks for change backs, delete the text. It should not have any.

I tried editing the AppSettings in safe mode before and it did not work so I thought that it was necessary to do as I described but it turns out all that needs to be done is merge the working narrowed down AppSettings while in safe mode over the top of the KEX24 settings. This works with Core,ini 20 and still using VKrnlEx.vxd 4.5.2.

So far I have noticed that the %WINDIR% preceding the rest of the directory in AppSettings does not work. The original MSI settings still work but if I use %WINDIR% or other % directory variables myself then the result with KEX on that module is that it is set to default. The numbering system is showing as it should, for example DW 1 for Disabled with the new installation. The editing in SafeMode will not work. A complete merge of unaltered AppSettings in SafeMode after delete and shut down :- (takes old settings out of RAM) will need to be done. I think this is to do with the order it is in, in RAM memory. Continuing on kext-diy-kernelex-extensions topic.