jumper

Auto-defrag?

Perhaps WPA2 Enterprise itself disallows repeaters as a means of greater security. Instead of a repeater, try cabling two routers together. Configure one as a client and one as an AP. You might need a switch or cross-over cable between them. Hopefully someone with more LAN experience than me can add some additional details.

So no quick hints. Did you find a solution? You may need to use an older browser that supports DTA when original timestamps are needed. RetroZilla maybe?

DbgPrint messages are not errors. They are debugging messages. If you want to hide them, don't use Kexbases.22 (or modify Core.ini).

Apps that can easily be recompiled should already work. I believe blackwingcat has already added support for all the differences made by newer versions of Visual Studio. This means the app itself makes calls that need to be back-ported -- sometimes simple, usually not.

That is the original version of PrintDlgW from KernelEx 4.5.2 that forwards to Unicows.dll and that didn't work years ago, sparking much discussion and a search for a working solution! What mode do you have Unicows.dll set to and what versions of kex files and extras are you using?

The switch under the keycap might have been damaged when the keycap got knocked off. Do you have a spare keyboard to try?

DX11? Please post the contents of the Kexstubs.ini file you are using.

DbgPrint is just the messenger--it displays a simple MessageBox that has nothing to do with files or the registry. The error occurs whether or not DbgPrint displays it. // // MessageId: E_FAIL // // MessageText: // // Unspecified error // #define E_FAIL _HRESULT_TYPEDEF_(0x80004005L) Enable logging on Wiashext.dll and report the last lines from the log at the time the error box is displayed. Same with RegSvr32.exe. You can also try disabling KernelEx on these two files.

@wimb: Win98 can't run x64 apps.

> I have PowerDVD7 set to KEX disabled and I get KernelEx - Ntdll.DbgPrint error window occurring on startup and shut down. Disabling KernelEx on an app does not disable it on submodules that are set to use a specific mode. The app needs to also be set to Override settings of individual modules. You are seeing the DbgPrint error windows now because DbgPrint is no longer a stub! The stub is still there and you can reenable it by specifying NTDLL.DbgPrint=kexbases.1 in Core.ini. This is already fixed in the next version. On the other hand, it's good to finally be seeing the error message so we can fix the underlying problem(s). What is/are the error message(s)? > I noticed that I do not ... even need kstub any longer !! Neither do I. It is still useful for testing new definitions and for working around UPX incompatibilities. > But when using a newer version of core.ini notepad 7.6.6 does not work. The default mode has changed so you need to manually set it to Win2000 (or as needed). Lowering the default mode should reduce the number of problems for new users and incompatibilities with various unofficial service and update packs.

> don't work as expected on the newer compilations Have you tried comparing app process snapshots of each setup? Use something like NirSoft's CProcess.exe to save a list of an app's process modules including version of each file in use.

What is the make and model of your mouse? There is no "top" position on the wheel, only up and down directions. The wheel is also a button, so you may now have the button taped "down". In Vista, untape the wheel, click it a few times and retest. You may need a better mouse driver (or to reinstall the current one). Google "download mouse test tool" for more help.

Wheel is stuck in scroll-down mode. USB mouse? Add a second USB mouse to the system. The first mouse will probably still cause scroll down to be stuck on. Uninstall (in Device Manager?) the first mouse and reboot. If needed try again with PS/2 mouse and with as many mice and ports as possible. Avoid hubs. Once you get a working combo, uninstall all extra mice, reboot, then reinstall original (or preferred) mouse.

@schwups - There is no change regarding IsProcessorFeaturePresent. It continues to be deactivated in Core.ini for non-NT modes. Try NT4 or W2K mode for apps/modules that need it. I'll see about creating an ITO(*) version that can be safely enabled for all modes. (*) ITO - ImportTable-Only. A "little" implementation or stub that is only used when a module won't load without it (Implicit link). KernelEx ITO functions do not resolve when delay-loaded (Explicit link) by apps probing for functions they want/hope to find. @MiKl - Yes, that message box is the new vDbgPrintExWithPrefix I just added. Thanks for posting the image--this is the very first time I've seen it (I was unable to actually test it). I'll change the ComponentID to display as hex (4294967295 is 0xFFFFFFFF or -1) and correct the va_list parameter affecting the Message text (already done, but not tested!).

I'm still working on the .21 documentation, but here's Kexbases.22 (with some docs inside) anyway: delta.22.7z - 130KB Improved debug support is the focus. Also some additions from discussions in the DIY thread. Thanks to @schwups, @roytam1, and everyone continuing the discussion here.

I don't think it will make a difference, but try "=f3e" instead. This is a clean failure. Kernel32.InitializeCriticalSectionEx returns a BOOL: 1 for success, 0 for failure. Ntdll.RtlInitializeCriticalSectionEx return an NTSTATUS: 0 for success, or error code. The parameters and action are correct, but not the return value. If Reader or KM is checking the return code, they won't know the initialization succeeded. I have already added Kernel32.InitializeCriticalSectionEx to Kexbases.22 and will post it soon.

> "webkit.exe - Entry Point Not Found" Use DependencyWalker to check both webkit.exe and Msvcrt.dll for _resetstkoflw. (answers.microsoft.com)

I see a scrollbar that isn't disabled. If that is the complete call stack, OllyDbg has a broken user interface...and either the stack trace is incomplete or you neglected to mention (among many other things) that the exception occurs at app launch before any user code is reached (in which case there is nothing to debug!).

I've never used OllyDbg, but try scrolling the Call stack window down until Called from shows the most recent call from a non-system DLL. Maximizing the Call stack window would give the best big picture.

RtlInitializeCriticalSectionEx is in Kexbases.dll; it doesn't need to be in ntdll.dll. Make sure extensions are enabled on Kexstubs.dll (BASE is best).

Debuggers must attach after KernelEx has loaded the app or plugin: In Ollydbg: File > Attach In VC5/6: Build > Start Debug > Attach to Process..." In Ollydbg: Options > Just-in-time debugging In VC5/6: Tools > Options > Debug > Just-in-time debugging Debuggers can also be manually configured in Win.ini or HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion to attach upon crash: [AeDebug] Auto=0 Debugger=C:\OllyDbg\OLLYDBG.EXE -AEDEBUG %ld %ld ;Debugger=C:\DevStudio\SharedIDE\BIN\msdev.exe -p %ld -e %ld ;Debugger="C:\Program Files\finesse.exe" -v -p %u -e %u

[Kernel32.dll] InitializeCriticalSectionEx=>Ntdll:RtlInitializeCriticalSectionEx Requires Kexbases.Ley0k or Kexbases.11 or later.

Your system should be a fresh (or well cleaned) OS install with no previous sound drivers or USP, DirectX, or KernelEx upgrades. The instructions on page 1 should work for the CT4780. Also, please read this CT4780 success story back on page 6.

The OllyDbg screencap shows the NULL pointer in EAX came from the first parameter. The code wants to check the first two bytes (WORD) of the input string for the disk designator sequence: "\\" (5C5C). Location of crash is in LoadLibraryExA_fix because LoadLibraryA_fix is: return LoadLibraryExA_fix (pLibFileNameA, 0, 0); Also, this is the last line in KM_ApiLog.txt: 4 fff78645 [XUL.DLL]02c0323a:LoadLibraryA(bfa4bb8c) bfa4bb8c is in Kexbases.dll (version 4.5.2016.20), so Kex wrapper of LoadLibraryA is called from XUL.DLL with return address of 02c0323a. Crash happens before LoadLibraryA returns. Kexbases.dll (version 4.5.2016.21) now contains a NULL-pointer check to prevent such a crash. (Note: over-explained in places for the benefit of non-programmers trying to learn.)