Leaderboard

I don't know the KernelEX file versions you use. I think the core.ini is version 20.e. Edit Kstub824.ini and try RtlNtStatusToDosError=n1. If this doesn't work disable RtlNtStatusToDosError in Kstub824.ini ( ;RtlNtStatusToDosError= ), reboot and check the functionality. I just checked Ntdll.dll's of ME and 98SE and noted that RtlNtStatusToDosError is already supported. So it should be removed from Kstub824. So at some point and somehow it slipped into the ini by mistake.

Unofficial Windows Vista x64 Extender Kernel step by step installation guide All the credits for the Extended Kernel go to @win32, not me. Disclaimer: I take absolutely no responsibility for any damage to your PC (or laptop or whatever) caused by following/misfollowing this tutorial. Backup everything before continuing. Special thanks to @winvispixp for guide improvement suggestions. List of Vista-unsupported programs that work with the extended kernel version 03092023 (current): Note: for best stability it's recommended to go for the October 2022 version (10192022) and only install 64-bit files (see step 8) Preparations: 1. Prepare a .7z extracting program (for example 7-zip). 2. Prepare Ubuntu or Linux Mint installation CD (for method 2 and uninsallation). 3. Update your Vista to 2017 EOL version (especially install sp1,sp2 and the platform update). 4. (Optional) You can install some server 2008 updates if you want. List of compatible updates by @LiptonAcer 5. (Optional but highly recommended) Install KB4019478 - D3Dcompiler-x64 update, .NET Framework 4.6.1 and 3.5, DirectX June 2010 redistributable and all the Visual C++ redistributables 64 and 32 bit. 6. Install SHA-2 Server 2008 updates in the following order: KB4039648-v2,KB4493730, KB4474419. 7. Backup your original files. 8. Extract the vistaexkernsetup_03092023.7z file (or vistaexkernsetup_10192022.7z if you are installing October 2022 version) into any folder you like (later called folder X). Method 1 - Automatic installation Method 1 involves using the Installer. If you are facing some problems, use alternative installer by @Bizzbob or method 2 instead. If you don't want to install 32-bit extended kernel, use method 2. 1. Copy your original kernel32.dll located in %systemroot%\syswow64, rename it to kernelol.dll and put the new file in syswow64 2. Run the setup.exe as administrator. (These steps do not apply to @Bizzbob's installer) 3. Follow the instructions on your computer’s screen. 4. Make sure that files like kernel32.dll are present in %systemroot%\system32. If they are not, use method 2. 5. Reboot the computer. 6. Repair file permissions. 7. Congratulations, enjoy Method 2 - Manual installation Method 2 involves using the Ubuntu live CD. The reason why we use Ubuntu and not another windows installation is because Ubuntu doesn’t support NTFS file permissions and thus ignores them completely making file replacing much easier. 1. Launch cmd.exe as administrator and run the following command without quotes: “bcdedit /set {current} nointegritychecks yes”. 2. Insert Ubuntu installation disk Either CD or USB (AKA live CD). 3. Reboot into the Ubuntu live CD. 4. Choose: “Try Ubuntu”. 5. On the top bar go to: Places\Computer. (This may differ depending on version of Ubuntu you have). 6. Locate folder X and copy all the dll and exe files from the folder X (EXCEPT setup.exe and files, that have filename ending with .wow64) to yourpartition:\windows\system32, click replace when prompted (make sure you have a backup). 7. If your Vista is UEFI, do the same for winload.efi. 8. (Optional) Move all the .wow64 files from the folder X to a different directory and remove .wow64 from their name, than copy them to yourpartition:\windows\SysWOW64, click replace when prompted (Right now 32bit extended kernel is in a very early stage of development, so personally I don’t recommend it for daily usage). 9. Shut down Ubuntu and boot Windows. 10. Repair file permissions. 11. Congratulations, enjoy Method 3 - Redirection If you don’t want to replace your system files, you can make specific programs use extended kernel dlls instead of vanilla Vista ones using local redirection. Unfortunately this method doesn’t let you run most of the new applications, that file replacing would do (for example there is a problem with exe files that spawn from another and many other). 1. Apply the DLLredirectionenabler.reg. 2. For each application you want to run with the extended kernel, do the following: 3. For exefilesname.exe create an exefilesname.exe.local folder. 4. Put files from folder X in the exefilesname.exe.local folder. 5. Congratulations, enjoy Repairing file permissions Automatic tool If you visit system32 after the installation you will probably notice that permissions for extended kernel files look like this: Obviously letting “Everyone” to modify your core system files causes a serious security issue so it is necessary to restore the default file permissions pattern: The owner should be: “nt service\Trustedinstaller”. Example: 1. Locate %systemroot%\system32\kernel32.dll 2. Open properties and under security tab click “Advanced”. 3. Make sure that “Include inheritable permissions from this object’s parent” checkbox is disabled. 4. Close the advanced window and click “edit” 5. Remove “Everyone” and other account that are not in the default pattern. 6. Add “Users” and “Administrators” accounts and set permissions for them to match the default pattern. The names have to be in your language. Look at other system files if you don’t know how to spell the words. 7. Add “SYSTEM” account and set permissions for it to match the default pattern. 8. Add “nt service\Trustedinstaller” account and set permissions for it to match the default pattern. They are different this time. 9. Click “OK”. 10. Open properties and under security tab click “Advanced” again. 11. Under “Owner” tab click “edit” than “Other users or groups”. 12. Enter “nt service\Trustedinstaller” without quotes. 13. Click “OK”. 14. Congratulations! Do the same for other files: If you have installed only 64 extended kernel than you have to restore file permissions only in system32 for the following files that you have replaced: ci.dll dwmapi.dll kernel32.dll ntdll.dll ntk32.dll ntoskrnl.exe ole32.dll powrprof.dll shell32.dll user32.dll uxtheme.dll winload.efi winload.exe api-ms-win-core-fibers-l1-1-0.dll advapi32.dll dxgi.dll dxgiext.dll api-ms-win-core-synch-l1-2-0.dll API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.dll API-MS-WIN-CORE-WINRT-ERROR-L1-1-1.dll API-MS-WIN-CORE-WINRT-L1-1-0.dll API-MS-WIN-CORE-WINRT-STRING-L1-1-0.dll api-ms-win-shcore-scaling-l1-1-1.dll bcrypt.dll shcore.dll userenv.dll useren0.dll kernel33.dll jobsrv.exe gdi33.dll gdi32.dll dwritent60.dll dwritent10.dll DWrite.dll api-ms-win-core-memory-l1-1-6.dll api-ms-win-core-memory-l1-1-5.dll api-ms-win-core-fibers-l1-1-0.dll api-ms-win-core-delayload-l1-1-1.dll api-ms-win-core-delayload-l1-1-0.dll If you have installed 32 bit extended kernel than you also have to restore access rights in syswow64 too (for the following files that you have replaced): kernel32.dll powrprof.dll ole32.dll shell32.dll user32.dll uxtheme.dll dwmapi.dll ntext.dll powrprof.dll shellnew.dll ntk32.dll miscstubs.dll ws2_33.dll ws2_32.dll user33.dll shell33.dll shcore.dll These are the final names for those files, remember that some of them have to be renamed during the installation as described in the guide. Optional Extended Kernel components d3d12.dll - This is DirectX 12 for Windows 7. You can copy it to system32. It does not work on Vista, but can be useful for Windows 8 users. Windows 7 Media Foundation Platform - This is needed for video codec support in some programs like Firefox. Making the Windows 7 mfplat system wide by installing it causes problems with Windows Media Player and Dremscene, so it's recommended to use redirection method instead: 1. Apply the DLLredirectionenabler.reg. 2. For each application you want to run with the Windows 7 mfplat, do the following: 3. For exefilesname.exe create an exefilesname.exe.local folder. 4. Extract the mfplatsetup.7z and copy all the dlls it contains to the exefilesname.exe.local folder. 5. Congratulations, enjoy 378.66_Vista and 398.11_Vista - Modfied Nvidia drivers for Vista. More details: https://msfn.org/board/topic/184056-breakthrough-p2-new-pascal-special-microsoft-nvidia-driver-port-for-vista-x64/ Windows Version Spoofer Version spoofer allows you to fool programs into thinking that you are running a newer version of Windows! Create an empty file called "osver.ini" (without quotes) in the %systemroot% folder. Put contents of the template below in your file. Adjust the template depending on your needs. Template: [Path to an exe file] Commandname=1 [Path to another exe file] Commandname=1 [global] Commandname=1 List of supported commands: Enabled (this one is always needed) MajorVersion MinorVersion BuildNumber CSDVersion PlatformId (2 is used to indicate that the OS is Windows NT. 1 represents 9x and 0 represents Win32s) to spoof Windows 7 sp1, use: Enabled=1 MajorVersion=6 MinorVersion=1 BuildNumber=7601 Windows 8.0 Enabled=1 MajorVersion=6 MinorVersion=2 BuildNumber=9200 Windows 8.1 Enabled=1 MajorVersion=6 MinorVersion=3 BuildNumber=9600 Windows 10 (the build number depends on the Windows 10 version, that you want to spoof) Enabled=1 MajorVersion=10 MinorVersion=0 BuildNumber=19044 Windows 11 (the build number depends on the Windows 11 version, that you want to spoof) Enabled=1 MajorVersion=10 MinorVersion=0 BuildNumber=22000 Example: [C:\Program Files\Mozilla Firefox\firefox.exe] Enabled=1 MajorVersion=6 MinorVersion=1 BuildNumber=7601 [global] Common errors If you're using an ISO from MSDN you may encounter an error "The ordinal 899 could not be located in the dynamic link library SHELL32.dll" while booting. you need to swap the explorer.exe from C:\Windows with the one called "replacement explorer". This error appears, when winload.exe's signature is different from the one expected by Windows. Make sure you have run this command: “bcdedit /set {current} nointegritychecks yes” and that you have replaced all of the required files. Make sure you have all the necessary updates installed. List of Vista-compatible programs that don’t work with the extended kernel. Windows Sidebar (resolvable): 1. Apply the DLLredirectionenabler.reg. 2. Create a "sidebar.exe.local" folder in %programfiles%\Windows Sidebar\ . 3. Copy your backup ole.dll to the "sidebar.exe.local" folder. 4. Congratulations, enjoy CPU-Z (old Extended Kernel version) - https://msfn.org/board/topic/183046-guide-vista-extended-kernel-installation/?do=findComment&comment=1207488 Kaspersky antivirus - https://msfn.org/board/topic/181612-wip-windows-vista-extended-kernel/page/112/ VirtualBox (as a host) - VirtualBox checks if system files were signed by Microsoft. (it is called "hardering") Windows Live Photo Gallery (only if you install 32-bit extended kernel) Feel free to report other programs. How to uninstall the extended kernel? Method 1 If you used Method 1 durning installation, the dlls were automatically backed up as [nameofdll].dll.bak. You just need to delete the extended kernel dll and then change the name of the vanilla one (delete the .bak extension; it should look like [nameofdll].dll after) Repair File permissions Method 2 Follow the Method 2 steps, but instead of copying extended kernel files, put your backup files back in system32 (or SysWOW64 if you are uninstalling the 32bit extended kernel) Repair file permissions. Method 3 Alternatively, file replacement can be done using Windows Vista PE. Boot from CD or USB Choose your keyboard layout and on the next screen click "Repair my Computer" and choose CMD. You can use 7-Zip or Notepad's "save as" dialog as GUI Put your backup files back in system32 (or SysWOW64 if you are uninstalling the 32bit extended kernel) Repair file permissions Old versions

I certainly have no issue with old thermal paste, for as long as it stays without having the contact broken with the CPU. I even have some decades old thermal paste on some things. While it is probably hardened like a rock, it shouldn't and doesn't cause me any issues unless i take the cooler off and put it back on.

The board photos on their site for the v1 and v2 are the exact same photo. For other manufacturers, often a V2 is not a change in specifications, but that the board is built using different parts, come with a different firmware somewhere, or is constructed differently electrically. There is nothing about the SATA ports being disabled when PCIe is used in any of their documents. They have a UK forum https://forum.giga-byte.co.uk/index.php/board,5.0.html

Thermal paste doesn't need to be wet at all. Its only function is to provide a path for heat to move from the CPU to the heat sink. So the fact that it is dry isn't a concern as long as that heat transfer is still occuring.

@tpao12 Try this one, good luck Dietmar https://ufile.io/5lqb6iig

@daniel_k this log doesn't have info about c0140001 AMLILoadDDB is parent wrapper on AML Interpretator, error can be anywhere before you can enable more debug options, but log will be HUGE, probaly you never see end of it ! example of custom DSDT under VM in extended debug mode ParseIntObj()/ParseString() and many other functions output more info to enable patch trace.c to

1 - Absolutely ! I'd say use a good thermal compound and change it once in 2 years it is enough if you don't game every day. 2- Aren't they suppose to throttle down the speed and/or shut down ? I'm not talking about CPU from the 80's , of course. 3 - Indeed you are ! You are supposed to play Spellforce , no ? lol

Well then as you say, maybe just a good CMOS and system reset was all that was needed. Me no expert, general consensus appears to be thermal paste drys out over time. Makes sense, it's applied moist and is repeatedly exposed to high termperature. On systems that haven't been refurbished in a few years it takes alcohol (solvent) and elbow grease to remove. Definitely in a 'drier' state than initial application. My goal is to preserve hardware indefinitely so it's not worth taking a chance. Fresh paste is applied every few years, usually every 3-5, to avoid risking a gradual or sudden overheating event that may fry the processor. If the BIOS is equipped with temperature sensor alarms, these are activated too. I have seen before where the heat sink becomes 'unglued' from the CPU, probably a combination of jarring and dried out paste, then it can no longer effectively dissipate heat. Sorry to hear your life isn't interesting. Chin up, there's always a (computing) adventure even in messed up times. I've been a bad boy lately, staying up half the night working on various computing projects, always something to tinker and learn, never enough time during the day.

Dearest @roytam1 In a previous post of mine, I made a point that, apparently, was not given the full attention it deserved... So, I'll re-iterate: Upstream (MCP) are currently further developing their platform (official UXP) with practically only one application in mind, i.e. official Pale Moon (the same can also be said about M.A.T. and his AuraRE platform, intended for his Borealis Navigator and Interlink applications). However, as things stand now, you also use your UXP-fork to build Serpent 52.9.0 (and several other forks, like the bin-oc+hyperbola ones), plus port UXP "patches" to Serpent 55/moebius... While NM28 may have a closer connection to the official PM codebase, both St52+St55 have distinct differences to PM, likely to become wider in the future; thus, one must be very wary/careful of official UXP patches as to eventual detrimental effect(s) on St52 and/or St55 (we've had recent examples of that, with disabled GMP (EME) plugins (CDMs) and "pdf.js" in St52... ) This very afternoon (despite the first heatwave - 37.5C/99.5F - of this summer....) I updated my St55 installation, from "basilisk55-win32-git-20220528-c952169c0-xpmod" to "basilisk55-win32-git-20220604-ea6e33cd0-xpmod" (or was that, perhaps, "basilisk55-win32-git-20220604-5600fe37e-xpmod" ? ) ; soon I discovered that the extension update feature was broken... While official PM has the "Tycho" AOM (add-ons manager), both St52+St55 have a "WebEx" type one, because they do also support Web Extensions (à propos, St55's WE support has declined to St52's levels, what with the recent Sync with UXP, but this is material for a future bug report ) ; also, in both browsers there exists the "extensions.update.background.url" pref, which can allow for setting up two different extension repos to watch out for add-on updates... In my copy of St55, I have extensions.update.url;https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=53.0&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=53.0&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% so that AMO would be monitored for updates of installed WEs, and extensions.update.background.url;https://addons.basilisk-browser.org/?component=aus&reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=52.9.2022.01.27&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=52.9.2022.01.27&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% so that ABBO would be monitored for eventual Basilisk XUL extensions updates (NB that, according to a MC statement I can't locate now in his forum, the ABBO repo may soon cease to exist...). The above "arrangement" used to work as expected until (& including) build "basilisk55-win32-git-20220528-c952169c0-xpmod"; "about:addons => Check for Updates" will produce an alert (View Available Updates) for, at least, four suggested WE updates from AMO: When moving on to "basilisk55-win32-git-20220604-ea6e33cd0-xpmod", "Check for Updates" stalls seemingly forever (being grayed-out), the AOM is in a permanent "Updating add-ons" state: The Browser Console is flooded with extension update manifest errors (for each checked extension), plus 19:22:10.249 1654446130246 addons.manager WARN Exception calling callback: ReferenceError: can't access lexical declaration `url' before initialization (resource://gre/modules/addons/XPIProvider.jsm:6686:1) JS Stack trace: UpdateChecker@XPIProvider.jsm:6686:1 < findUpdates@XPIProvider.jsm:7574:5 < doCommand/<@extensions.js:1168:15 < safeCall@AddonManager.jsm:191:5 < makeSafe/<@AddonManager.jsm:206:25 < process@Promise-backend.js:917:23 < walkerLoop@Promise-backend.js:801:7 < scheduleWalkerLoop/<@Promise-backend.js:737:11 I have verified locally that the culprit for this breakage is in fact: ported from UXP: Issue #1909 - Guard against empty update manifest URL (7b3f9fb7) "UXP: Issue #1909" shouldn't apply as-is on Serpent 52.9.0 and 55.0.0, because they have Extension Managers different to the one in official Pale Moon; so please, revert both https://github.com/roytam1/basilisk55/commit/5600fe3 (for St55) and https://github.com/roytam1/UXP/commit/7b3f9fb (for St52) Thanks for understanding, best regards

you may check BuildID to see if certain feature is available or not. queueMicrotask: since 20220325000000 optchain: since 20220505000000 nullish coalescing: since 20220523000000 checking platform version from my builds can only distinguish if js-optchain and js nullish coalescing is really not available in platform code or not. (i.e. 4.8.4 or older don't have them, 4.8.5 may have them but depends on BuildID) since those features are not available before I bump versions: https://github.com/roytam1/UXP/commits/9816e341b29ac8f3eb5223a6528197e88b381e22