jumper

MiKl> SUNBIRD verursachte einen Ausnahmefehler 03H in Modul KERNEL32.DLL bei 0187:bff768a1. A Google search for "03H KERNEL32.DLL bff768a1" led me to this post by jds, so clearly the Active Context (*ActCtx*) stubs are not working and need to be removed. SAP GUI for Java will surely break for jds when he tests with the "new" definitions because of this regression. Also, make sure you have the Kex default in Core.ini [ApiConfigurations] set to "default=2" (WIN98). default=5 is incorrect. Your system seems to have mismatched msvcrt DLLs or other DLLs used by Sunbird that are causing the problem, not Sunbird itself. If your default is already at "2", please disable KernelEx extensions completely on Sunbird. > After closing the error box another message appears saying that NEGOTIAT.DLL is missing. This has to do with Directory Services. Maybe Sunbird is trying to access Outlook? This doesn't seem to be related to Kex or Kext. > When using the new defs Sunbird and OpenOffice crash no matter if iphlpapi 3 or 4 is 'called'. Is this the correct term ? "Called" is okay; "active", "used", "being used" might be better. The Active Context stubs seem to be the problem, not iphlpapi4--this is good. >Commenting out the msvcr... sections seem to have no positive effect on my system. Okay, thanks. It now looks like iphlpapi4 is probably okay; the problem seems to be the ActCtx definition regression. I'll correct post #116

Thanks again to everyone for testing. It seems I've make too many changes all at once and it's not clear where something has gone wrong. @MiKl: Sunbird 0.5 (zip version) does not require KernelEx (Depends and IP36 both give it a clean bill of health). It runs fine in 98SE for me with Kex disabled or in any mode. It does link to Iphlpapi.dll but has no problems with iphlpapi4 using either the Kexstubs or local copy method. Using the local copy method I can see in a process viewer (TaskInfo2000) that both the original and wrapper are loaded. Questions: Are you using the new definitions? Are you using the Kstub or local-copy method? "Crash" is extremely vague--can you provide some details? @schwups: "...IpHlpDll Entry not found (7b340000 0)" is my debug message from the DLL startup function as the load is about to fail. 7b340000 is the address returned by LoadLibrary for C:\Windows\System\iphlpapi.dll and 0 is the address returned by GetProcAddress for ??? (silly me for not including the API name in the debug message ). It appears from the log that it actually loaded successfully on the first call to GetAdaptersAddresses, then failed on the second call--this could be because it follows a call to CreateActCtxW (that has caused trouble in the past) or something to do with how KernelEx hooks GetProcAddress. Try commenting out Kernel32:CreateActCtxW (and rebooting); if that doesn't help, please try the local-copy method. @jds: Can you test using the Kexstubs method (clear the KnownDLLs entry and use the new definitions)? It looks like the global- and local-copy methods might be immune to something that is ailing the Kexstubs method. For anyone experiencing R6034 runtime errors in OpenOffice or other apps, try commenting out the Msvcr90 and/or the Msvcr sections-> "[;Msvcr90.dll]", "[;Msvcrt.dll]". [ reference1, reference2 ] If the three of you can confirm that apps that worked with iphlpapi3 and older definitions also work with iphlpapi3 and the new definitions, that will isolate iphlpapi4 as the problem. If modifications to the new definitions are needed to get iphlpapi3 to work again, perhaps iphlpapi4 will also work.

Ktree9 has been posted. I was over-thinking the sorting thing. The solution was to do all inserting at the end, then make one call to TreeView_SortChildren for each group once the inserting was done. Load time is now less than one second !

I, too, was able to run SumatraPDF 2.2, but printing didn't work (page fault). I didn't install, but ran the 7-Zip-extracted version as usual. 2.2 is loading very fast once again like 1.9 did (2.1 was much slower to load). BTW, printing works in 1.9 and 2.1 with the help of the updated COMDLG32.DLL.

I vote to leave it here. A more general SATA<->IDE topic can be started in Hardware that can point back to this one for reference.

SeaMonkey 2.0.14 is an W2K-compatible version; SeaMonkey 2.14.1 is the latest XP+ version, is not W2K-compatible, and is NOT a minor upgrade to 2.0.14! I suggest trying 2.6.1. It should work with the new Kexstubs definitions. After that, try 2.9.1 -- it is the last W2K version. ImportPatcher.37 reports the following for SeaMonkey.exe and plugin-container.exe: ... [DLL replacements] RASDLG.dll= [RASAPI32.dll] RasGetAutodialAddressW= RasGetAutodialEnableW= RasGetAutodialParamW= RasSetAutodialAddressW= [RASDLG.dll] RasDialDlgW= RasPhonebookDlgW= ... Thus it requires these additional Kstub definitions for SeaMonkey.exe and plugin-container.exe: [Lz32.dll] --- all API's in functions that use KnownDLLs to forward to LZ32 --- RasDialDlgW= RasPhonebookDlgW= [RASAPI32.dll] RasGetAutodialAddressW= RasGetAutodialEnableW= RasGetAutodialParamW= RasSetAutodialAddressW= [;RASDLG.dll] --- see Lz32 --- RasDialDlgW= RasPhonebookDlgW= (Note how easy that was to cut and paste from one .ini to another!) and this addition to the registry: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "RASDLG"="LZ32.DLL" Now back to 2.14.1 -- its plugin-container.exe requires many more new definitions that will probably be more difficult to implement. Its SeaMonkey.exe does not require the 1.9.1 additions, however, and should work with the new definitions. Try disabling plugin-container.exe (and thus plug-ins) by renaming or deleting it. Finally, if someone could look up those Ras functions above and recommend proper definitions, that would be great!

I've been wondering the same thing for some time now. Perhaps even a VM directly on one of these new super-BIOS'es. Basic hardware would finally become standard; I/O could happen in the background on extra cores; etc. I suggest opening a new Topic because it's only a matter a time before this becomes a major issue!

Thanks to everyone for the testing and feedback. In a slight change of plans, today I'm releasing Iphlpapi4 (Post #1 and Below) and updated Kexstubs.ini definitions (Below). Iphlpapi wrapper Usage with Kexstubs: * Put iphlpapi4.dll in your Windows\KernelEx folder and activate the individual functions in Kstub822.ini: [Iphlpapi.dll] GetAdaptersAddresses=>iphlpapi4: GetPerAdapterInfo=>iphlpapi4: Usage without Kexstubs (or without KernelEx): * Put a copy renamed to iphlpapi.dll in the folder with any app that needs it. * Disable KnownDLLs redirection for Iphlpapi.dll by deleting this key in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI History: Iphlpapi3 implemented GetAdaptersAddresses with information from GetAdapterInfo. Also stubs for GetPerAdapterInfo, GetTcpTable2. Iphlpapi4 implements GetAdaptersAddresses with information from GetIfTable. This adds the Loopback interface to the results as well as real MTU, OperStatus, and link speeds. But lost is DhcpEnabled status (and potentially Gateway and DNS details that I hadn't implemented yet). Stubs for CancelIPChangeNotify, EnableRouter, FlushIpNetTable, GetBestInterfaceEx, GetExtendedTcpTable, GetExtendedUdpTable, GetIpStatisticsEx, GetPerAdapterInfo, GetTcpStatisticsEx, GetTcpTable2, GetUdpStatisticsEx, UnenableRouter. Iphlpapi5 is to be the best of 3+4 and more. But I've been finding lots of errors in MS and third-party documentation and sample code, so I need empirical data to clarify how things should actually work. I will be converting a number of console test apps (based on MSDN samples) into one Win32 app that can be run on any 32-bit Windows platform. Results from dual-boot and VM systems should provide the needed clarity! Updated Kexstubs.ini (Kstub822.ini): Kstub_KnownDLLs.reg REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "CREDUI"="LZ32.DLL" "DBGHELP"="LZ32.DLL" "DNSAPI"="LZ32.DLL" "WINHTTP"="LZ32.DLL" Edit: removed ActCtx / Active Context and Msvcr* definitions Edit2: struck Kex from stubs.ini

>> The System directory is the one place it cannot go! > ...this time I renamed your DLL as IPHLPAPI.JMP and placed it in the System directory, then added the following registry entry... Well, yes, this advanced method is the exception, but it's a global solution that affects the OS and all apps! Test versions cannot override it either by local installation (requires clearing the KnownDLLs entry) or by KernelEx/Kstubs. I recommend using the iphlpapi3.dll name for easier upgrading when the time comes. > Now HoverIP and SAPGUI work just fine! Good, hopefully Opera now does too. > Hmmm ... I've noticed you mention using Bubble Sort a couple of times previously, AFAIK, it's the world's slowest sorting algorithm. Actually, it's the fastest in practice (and nearly in theory) when the dataset is very small or presorted (or nearly so). The slowest in practice is a pure quicksort on reverse-sorted (worst-case scenario) data! Standard quicksorts shuffle (or bit-reversed-index) the data first to vastly decrease the likelyhood of a worst case scenario at the cost of slower average performance. The simple methods have low overhead but don't scale well; the more complex the algorithm, the larger the dataset must be before it become faster. Hybrid implementions often bubblesort small datasets and do a brief analysis on larger sets before selecting what will hopefully be the fastest method. > I've had dramatic improvement in another project where I converted a Bubble Sort into a Shell Sort, only slightly more complicated - I highly recommend it (I ported the example from Peter Grogono's book 'Programming in Pascal'). Ktree processes presorted lists of api names from get_api_table() calls and raw DLL export tables. For the "All API's by name" list, I can do an insertion sort as I process, or load all lists then do a merge sort.

> Thanks Jumper. And Thanks to you, MiKl. There have been 26 downloads of v3, but only you and jds have reported your finding. > I have tried the kstub822.ini method but I am not sure if it had any effect on my system. "No" effect is the best effect when it is not needed! > SeaMonkey 2.0.14 does now start and works perfectly Good. This is back to the "no" effect when not needed. >... but SeaMonkey 2.14.1 still crashes 'blaming' msvcr100.dll. If this means missing exports, you need to update to the latest msvcr100.dll package. > To avoid misunderstandings - I just c&p the four lines from post #101 into kstub822 (I did put them between credui and kernel32) and re-start, correct ? Yes, but that was so "2012". The "2013" method (see updated post #101) is to rename it iphlpapi3.dll and edit Kstub822.ini to match. The change is immediate--no reboot needed! >When you have the time could you test SeaMonkey 2.14.1 on your system ? I can't risk my FF2 setup, but I'll download SM and check it out.

> I copied to the System directory... My IPHLPAPI.DLL is a wrapper, not a replacement. The System directory is the one place it cannot go! > ...and commented out all the IpHlpApi section in "stub822.ini". This isn't necessary unless you use the "content= iphlpapi, Kstub822" method (currently suspect, testing requested!). > PS. A small request for ktree9 : If it isn't too much trouble, would it be possible to sort the DLL names listed under, eg. 'kexbasen'? Like in this Nov 4 test build? Ktree9h.7z Pardon the 10-second hourglass--that's the slow built-in sorting taking place that I've been wanting to correct before release. All the apis in each dll are already sorted, so I just need to do a custom merge-sort in most cases. Three later builds correcting various minor issues also exist, but aren't as usable.

I checked the SeaMonkey 2.6.1 package and didn't find any iphlpapi dependencies or even raw text references. I looked at the SeaMonkey sources and the only reference to iphlpapi is in nsNotifyAddrListener.cpp, the same version as used by FF2..20 and the 1.9.1 core, and the one I have already been using for reference. Apparently that file isn't linked into the 2.x builds of SeaMonkey. So, any problem should also show up in FF2..20. But I've been running with no problems for the last week using the Core.ini method: contents=std,iphlpapi,Kstub822,kexbases,kexbasen You can try using the Kstub822.ini method and only add definitions for GetAdaptersAddresses and GetPerAdapterInfo as needed for other apps: [Iphlpapi.dll] ;any or all of the following: GetAdaptersAddresses=>iphlpapi: GetPerAdapterInfo=>iphlpapi: Iphlpapi.dll can also be renamed for testing in methods other than the local-app-directory method.

In the top-right corner of your diagram, is the active speaker connected to the speaker jack on the PCI card or to the line-out jack?

CPU or memory may be overheating. Try underclocking both, cleaning all heatsinks, and wiping dust from all chips. Next time the problem occurs, be prepared to run thorough cpu and memory test programs immediately after rebooting.

What Iphlpapi dependencies does Dependency Walker list for SeaMonkey? GetAdaptersAddresses was written with Firefox in mind--I studied the 1.9.1 source code (nsNotifyAddrListener.cpp) and looked at the latest as well. And what method did you use? Try using Kstub822.ini to add the functions one-by-one. Note: Kexstubs definitions will override the local copy method. (In case you already have definitions from previous tests.)

Merry Christmas! Version 3 of the Iphlpapi wrapper (2.55K) is now available with near XP-level support for GetAdaptersAddresses and partial support for GetPerAdapterInfo. (There is also a stub for GetTcpTable2.) To use with KernelEx, copy to iphlpapi3.dll in your Windows\KernelEx folder and activate in one of these ways: [*] add individual function(s) to Kstub822.ini: [Iphlpapi.dll] ;any or all of the following: GetAdaptersAddresses=>iphlpapi3: GetPerAdapterInfo=>iphlpapi3: GetTcpTable2=>iphlpapi3: To use without (or with) KernelEx: place (a copy of) iphlpapi.dll in the folder with any app that needs it. Disable KnownDLLs redirection for Iphlpapi.dll by deleting this key in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI Edit: First method not working yet; Last method most tested and working both with and without KernelEx. Edit2: Needs to be named iphlpapi3.dll in KernelEx folder. Edit3: Second method not working yet. Non-working methods hidden in Spoiler.

Good. Before reflashing the BIOS, you can try resetting it (with a jumper or by removing the battery) and then reloading the BIOS defaults. If you previously added the CD drive to the same cable as the HDD, the HDD may not have been jumpered correctly to allow the controller to see the second drive. If you previously attached the CD drive with a separate cable to the secondary controller connector, you can try putting it on the same cable as the HDD. The first goal would be to get both drives to be detected and show up in the BIOS setup. Then when you are booting to DOS, they should also both show up in the hardware summary screen just before DOS begins to load. Did any of the CD drives ever get detected and show up in the BIOS setup or in the boot summary?

Wash the card then test in another system. Do not connect cables for front panel module! If problem persists at line-level output jacks on card, diagnose the analog channels on the card as follows: monitor the audio signals with a monophonic, (battery-) powered speaker with two probes for inputs. play a monophonic sound that clearly distorts when you think it shouldn't if it sounds the same at both channel jacks, it's not a one-channel problem (i.e. bad cap. in one amp) probe the circuit, tracing the audio signal from the line-level outputs back to the DAC (digital-analog converter) if audio clears up during the trace, identify the faulty component. if the audio is already distorted coming out of the DAC, the card is unfixable.

I think tomasz86 is right: Version 5.1 would be Windows XP. The other two strings seem to be symbols rather than function names.

Your CD drives may be just fine--it sounds like the controller is disabled in the BIOS or you have a bad cable. Now (before you install a new system) is a very good time to revisit your BIOS settings and check all the hardware cabling. In BIOS, make sure both IDE controllers are enabled and then have them autodetect the attached drives. I recommend putting the HDD and CDR on different controllers (different cables) both jumped as Master. Use new cables if you have any. If you only have one good cable, you can put both drives on the same cable. Put the HDD (jumped as Master) on the end connector and the CDR (Slave) in the middle. You will be much happier with this system once you get it running if it has a working CD drive!

@SearanoX: Use Find to search for the text "LdrLoadLock" in files of type *.dll and *.exe in your Windows folder and below. Expand the search as necessary until you find something--It has to be there somewhere! Once you get some hits, use Dependency Walker to confirm. Edit: Just did a Google search and found out there is no such thing as "LdrLoadLock"--did you mean "LoaderLock", "LdrLockLoaderLock", or perhaps "LdrpLoaderLock" ???

An HRESULT is a long int. Using t/-1 is a convenient way of setting the "error" (most sig.) bit. Perhaps SAPGUI treats >0 as recoverable errors and <0 as fatal errors? I was able to add a 6-byte stub (jump to address in jump-table) for each API in my wrapper, so it now can be imported in the standard way. The extra jump table is trivial to create in the loader, and still allows this wrapper implementation to access the original sysdir DLL without needing any file renaming/duplication, etc. iphlpapi.zip GetAdaptersAddresses returns ERROR_NOT_SUPPORTED. GetPerAdapterInfo attempts to function, but probably just returns SUCCESS and an empty list. (see below) GetTcpTable2 returns ERROR_NOT_SUPPORTED. I've been studying the Wine 2003 and 2006 sources for iphlpapi as well as the ReactOS fork (off Wine 2003). With the help of some Wine header files plus a winetypes.h of my own creation, I've been able to extend my VC++5 build environment to handle the Winsock2 and IP Helper API's. I couldn't find an iphlpapi.lib to link with, so I created my own. I've built the MSDN examples for the following seven iphlpapi.dll functions: GetAdaptersAddresses GetAdaptersInfo GetIpAddrTable GetIpForwardTable GetTcpStatistics GetTcpTable GetTcpTable2 Yesterday I searched Google for "getadaptersaddresses sample output" and found a webpage that has the same MSDN GetAdaptersAddresses example along with the (XP?) output. Unfortunately, this site doesn't contain any GetPerAdapterInfo info. I already have a partial implementation for GetPerAdapterInfo, but the Wine/ReactOS sources call upon their own system internals that I had to stub. As a result there is no meaningful data returned yet.... But now I can get to crafting a GetAdaptersAddresses replacement.

> A function of the Win32 API failed This could be a general failure message, or it could mean that HoverIP v1.0 is import-table-linked to iphlpapi.dll. > Error No -2147467263 > 'E_NOTIMPL: Not implemented' SAPGUI is definitely delay-loading iphlpapi.dll via LoadLibrary / GetProcAddress. Let me explain.... The technique of rewriting the DLL export tables at load time works great when the DLL is delay loaded: LoadLibrary loads the DLL into memory and activates the export-table rewriting code; then GetProcAddress reads from the rewritten export table. The normal loader merges these steps and accesses the DLL's export table before executing the entry function. Why? Because it's still checking dependencies and hasn't decided yet whether to execute the parent app! What this means: This technique can be used to implement two different functions with the same name based upon how the DLL is linked or loaded by an app! ...It also means it won't work for our purposes at this time. Stay tuned for the exciting backup plan.

This step should also be preceded by backing up the registry (so it can be restore later if things get worse rather than better) and the BIOS reset to defaults per RJARRRPCGP's post (first writing down the current settings per buyerninety's post). Then to state it more clearly: + if detection problems for other devices persist, cold boot into Safe Mode and remove ALL hardware drivers (especially for the mainboard!) Followed by a cold system restart / normal boot with hardware autodetect. Control Panel->Add new hardware can be invoked if anything doesn't autodetect.

>ISA Sound card stopped functioning (no sound) - device manager suggested a problem - reinstall driver. Some possible causes (and actions to take) for this root problem: CMOS battery died / BIOS IRQ settings changed + Voltage should be at least 2v else replace battery; reset BIOS; set IRQs as needed Registry / drivers corrupted + scandisk HDD to ensure it's not a wider issue + In DOS, "Regedit /restore" last saved registry prior to failure + "Regedit /fix" current registry only if no viable backup Sound card died + shutdown and pull the card + if detection problems for other devices persist, remove ALL hardware (especially mainboard!) drivers in Safe mode + optionally: reinstall sound card once everything else is working and backed-up (if you dare) Mainboard failure: dust in other sockets fried ISA bus; something got zapped; etc. + short term: clean thoroughly; you might be able to run with reduced functionality + long term: replace mainboard I strongly suspect a battery failure, BIOS change, or addition/removal of cards that would change IRQ settings. Most devices are plug-and-play and Windows would adjust, but non-PNP devices such as ISA cards would need redetection. If you did anything in the BIOS or anything inside or outside the case (plugging in or out cards or cables) prior to the sound card failure, please report.