Thank you. I am at a bit of a loss trying to find a way to download an iso for 23H2. Everything I find is already outdated. On Microsoft’s website there are only options for 24H2… If you know a legitimate place from where to download 23H2, please share. I’ll be happy to try that.
Thank you for replying. As I was typing this, I got a new crash ON BATTERY only, so this may be worse than I thought. Grey screen first, then immediate reboot.
I checked event viewer, Windows logs, System. I see one Critical event, which reads “The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.”
It is preceded by a number of Information events about ACPI thermal zone. Immediately after the critical event, another information event “UMDF reflector is unable to connect to service control manager (SCM). This is expected during boot, when SCM has not started yet. Will retry when it starts.” It is then followed by a warning event “The driver \Driver\WUDFRd failed to load.
Device: ROOT\WINDOWSHELLOFACESOFTWAREDRIVER\0000
Status: 0xC0000365”
A few more warning events like the above follow (amid lots of information ones):
Device: HID\FRMW0005\4&94936f4&0&0000, Status: 0xC0000365
Device: USB\VID_27C6&PID_609C\UID0F10D23E_XXXX_MOC_B0, Status: 0xC0000365.
I don’t find a minidump folder (C:\Windows\minidump), even though I have had a number of BSOD during boot, during recovery. Even if I do find one eventually, I’m not that advanced to analyse such logs myself.
No crash (on battery) for the last 10 minutes while I am typing this. But I am feeling a bit hopeless and am hoping this is not a hardware issue. I will open a support ticket just in case. I’d hate it if having the FW didn’t work. On another computer, I installed Windows from the same image in a Proxmox virtual machine (i5-7500t), and no issues there.
Thanks for any further tips.
The dump logs should be pretty easy to analyze. If you do not know what they mean, you can easily find the information online.
Please also make sure to only use the graphics driver from Framework. AMD’s driver is ahead of the Framework version and there have been multiple people reporting black screens after updating their device using AMD’s driver and not Framework’s.
To reset your graphics driver:
Install Display Driver Uninstaller (DDU) which you can find online. Then remove all the graphics drivers already present on your system and run the Framework driver installer again.
Thank you, @Elliot_Lu! I first had only the Framework drivers installed. The problem was there. Then I found AMD’s, but it didn’t change anything. I will try your suggestion, maybe something didn’t install correctly. It might be a driver issue, since this never happened on Fedora.
Whenever I get a BSOD, there is always a different error. Unfortunately, before I manage to note it down, the computer restarts… As with logs - good to know they are digestible. My problem is not so much difficulty, it’s time. Nevertheless, we need to appreciate the irony that we have a great machine that works perfectly in linux, but suffers from driver incompatibilities in Windows 
Hoping to get some time to do what you suggest, and will then share how it went. Thanks!
I would reach out to support right away. They should have an idea about compat with 24H2. This sounds like a hardware issue. What are all the BSOD you are getting? You may try to startup in safemode and try doing a sfc /scannow. I would also try booting with all expansion modules unplugged, with a single stick of ram in left slot and then a single stick of ram in right slot.
You should be able to find an older iso. Try web archive. If it isn’t a specific problen with 24H2 its likely your drive or ram are faulty. Could be the mainboard as well but I’d rule out the others first.
You could boot up the linux live environment and check the smart stats of the drive and also dmesg for weird errors.
I think in rufus you can choose to download the iso a d also what version. Try that.
Edit: To rule out a drive issue rufus could make a windows to go install on a usb drive if you have one.
I have a dual boot of Windows 11 24H1 on the 7640u mainboard that is 100% stable.
Thank you, @parawizard! I did a memtest, and all looks good with the memory modules (bought them brand new for the FW13). WD drive was also bought new, I installed WD’s software, it says latest firmware on the drive, no smart errors. Nothing specific in fedora dmesg, as far as I can tell.
I will check with Rufus, although I think it only offered choice for language, rather than version (latest Rufus from their website). But I may be wrong, will check it later today.
Doing sfc /scannnow (followed by dism commands about check/restore-health) reports all errors fixed and everything good. But then on next power plug in, same crash. Interesting that it only happens on Windows, not on Fedora (I will also try OpenSuse, but I have to choose between the FW13 and sleep, so am being slow with these experiments). This strongly suggests hardware fault might be less likely. I sent a support request, let’s see what they can do.
Thanks again, I will write updates as I have them.
I had this locally. Uploaded to my drive for you to download. The hash seems to match what this search says. I use HashTab that integrates on explorer file properties to calculate and compare.
ISO:
Win11_23H2_EnglishInternational_x64v2.iso
Hash:
705AC061688FFD7F5721DA844D01DF85433856EAFAA8441ECE94B270685CA2DB
Many thanks, @parawizard, very kind of you! Downloading now and will see. Meanwhile, the Rufus win-to-go route did not work as hoped. Upon boot, it gets into a BSOD claiming it cannot find the boot device. I read it is a normal thing as USB drivers are not loaded in time for the boot loader to be able to access usb media and that the feature is no longer supported. So not much luck there.
Let’s see what happens with the 23H2 version…
Windows to go works just fine here on the same mainboard. It’s definitely supported. Lets see how 23h2 works but id you have issues with that as well I think you’ve got a doa mainboard.
@parawizard, I am afraid same things happen on 23H2… I kept the computer on during setup. The moment it restarted the first time, it crashed immediately upon starting the Windows boot (when the circle shows). That was followed immediately by a BSOD, which displayed some new error, but it disappeared and the computer restarted before I was able to take a photo.
I then unplugged the power, and started again. Everything installed correctly, and I booted into the desktop. Installed the FW driver bundle. The computer restarted again and I was able to log in. Then I decided to plug in the cable. A few moments later, it crashed to a grey screen and restarted. It could not boot, it just stayed black, and the fans started spinning.
What’s more concerning is that I also experienced a crash while using Fedora. It was working fine until one moment it got into this same grey screen and rebooted. I had installed Fedora on a 64 GB USB stick this time.
So, I am now waiting to hear from Support. It’s been 24 hours, and only an automated message to upload any photos if I had them… I am afraid this is indeed a hardware problem.
And I also noticed another forum user posted about a similar issue. I hope this will get resolved professionally and in a timely manner. Thanks to all who offered help! I will try to post updates as I have them. Meanwhile, any further tips to check things on either Windows or Fedora are of course welcome!
Yep definitely bad hardware. They’ll get you sorted.
Interesting finding! In another post, I read someobody had 5200 MHz memory modules and when they exchanged them for 5600, all went well. I remember to have ordered one of the modules indicated on Framework’s site, but when I checked with hwinfo, it showed 5200. After a bit more of reseach on the specific product number, I discovered Crucial had problems with some 5200 MHz modules and were offering free under-warranty exchange to customers who had them. The numbers on mine matched those recalled. The modules I had were not the modules I ordered - THEY WERE MOST LIKELY REPLACED IN THE BOX, which read 5600, while the modules had the numbers for 5200 MHz sticks. Of course, the issue may be down to the speed and not to a fault in the modules themselves…
I initiated a replacement with Amazon, hoping this would be the solution. Sharing here as it may well be the culprit. Will report back when I get/install the new modules (5600 Mhz, fingers crossed).
I also tried switching from 5200MHz RAM to Crucial 5600Mhz but still have the issues with hard crashing.
I will share an update in a few days after I have had more time with the laptop.
However, after I changed the memory sticks, all has been well and stable. There are still a couple of things I need to exclude (e.g. the amount of RAM available to the gpu, currently it’s 2gb; allow 100% battery charge, as currently set to max 98%).
In my case, I went with Corsair Vengeance 2x32gb, CMSX64GX5M2A5600C48. While finding out my RAM issues, I stumbled upon a message on Crucial’s website about some defective batches. I can’t find it right now, but try looking for it, and check if your number (not what Crucial calls ‘material number’ but the actual CTxxx code) shows up among the list of affected ones. If so, that might be it.
UPDATE!
After the change of the RAM sticks (2x32gb Corsair 5600 Mhz), everyting is stable - no more crashes, no BSOD. Windows 11 24H2 and Fedora 40 work perfectly well alongside each other. Therefore, I could only conclude it was either the speed of the RAM sticks I had received (5200 MHz) or the sticks’ being faulty themselves. Or both.
Hi,
Just curious, now that you know the problem was the ram, does memtest detect the problem?
I guess this is an example where ECC would have narrowed this down immediately.
I was able to run memtest upon boot once. I didn’t see it reporting any errors, monitored it for a while before I went to sleep. Next morning the computer had restarted itself, so if there were any report or a crash midway, I can’t tell. I did some kind of memory test from Windows too, which had not reported any errors.
Impossible for me to judge if ECC would have been the solution. I read on crucial’s site for a problem with certain batches, mine were among those affected. However, when I tried to request warranty service through the website, it kept telling me that the “material number” was invalid. I was too busy to keep digging, so I just ordered a replacement choosing a different brand altogether and making sure it was 5600Mhz. The crucial sticks I ordered were also supposed to be 5600, but what I got was 5200, and I wouldn’t have paid attention had it not been for a tip on this forum.
In conclusion, while it appears that the problem was (due to) the RAM, I can’t be certain if it were the speed alone, or something else in addition.
Glad the RAM swap has resolved your issue! I was unable to find anything about bad batches of Crucial RAM, if you happen to stumble that info please do share it here. Thanks 
I think it was this Certain Crucial modules eligible for warranty return | Crucial EU.
The module I had received had this number CT2K32G52C42S5, which you can see in the list.