On Boot Failures
Headlines everywhere on Friday, the 19th of July, 2024 were about the massive computer outages caused by a faulty update to the CrowdStrike antivirus software. It seems some config file choked up a kernel module causing Windows machines to fail with the infamous Blue Screen of Death.
I recently started a new job and was perhaps a little smug in the fact that in my new job I am no longer responsible for hundreds of endpoints running CrowdStrike.
Karma's a bitch though.
I shut down my home PC Friday night to install a memory upgrade and after powering it back on I was met with the very same Blue Screen of Death.
"A critical process died" it told me, with no information about what said process actually was.
And no log files.
And no dump files.
System Restore failed. sfc /scannow failed. dism /cleanup-image failed. Everything I could find failed. I couldn't even just reinstall Windows over the existing installation because apparently that requires being already booted into the OS that currently isn't running.
The log files from dism led me to believe the problem might be related to registry corruption, but my attempts at replacing system registry files with clean ones from an install wim were not successful.
I was grasping at straws. Starting from scratch with a clean install is daunting and would have set me back weeks. I was contemplating pulling out an old SSD and just running with Linux Mint for a while.
Through desperation, I downloaded Hiren's BootCD PE so I could poke around a little more. None of the tools included there were able to resolve the issue either, but just having access to a standard Explorer shell and a web browser helped.
Finally I came across ShadowCopyView, a program that can explore the System Restore images that Windows (can) take regularly. In one last desperate effort, I moved out all of the system registry files from C:\Windows\System32\config and used ShadowCopyView to replace them with copies from an automatic restore point the previous Monday.
That actually did the trick. I was able to reboot into my primary Windows partition and sign in like normal.
I have no idea what may have been lost in a few days of registry updates, and I have no idea what may have caused the problem to begin with. But I am happy I was able to find something in the end that would get me back into my system without having to reinstall everything from scratch.
... Although maybe I should anyway.
And should anyone encounter something similar in the future, these were the kind of errors I was seeing that a Google search wasn't really coming up with anything useful:
dism.log: failed to open registry root
dism.log: failed to query for path to user profiles directory
dism.log: failed to load the default user profile registry hive
dism.log: failed to load offline store from boot directory
srttrail.txt: pending package install
strtrail.txt: boot manager generic failure
28 notes
·
View notes
shoutout to that one time i had a dream where my computer was having horrible crashes and then a program opened up on it that was like this super old Star Trek computer troubleshooting program that was almost like an interactive game thing. like it started out with a title screen of the Enterprise flying across the screen with the Star Trek logo and the main theme playing, and then an FMV would play of Picard, Riker and Data all standing around a glossy table in a glass space station getting a communication (likely from Worf) that the user's computer had crashed wasn't working properly, then Picard and Riker would look at each other and go "well, that doesn't sound too good, doesn't it?" "indeed it doesn't, Number One." and then they'd all turn to the viewer. the camera cut to Riker, who, with that beautiful smile of his, was like "why don't we try to figure this out?" and then it'd take you to a super retro looking troubleshooting menu that was a mix between the LCARS look and a metallic plate. the menu had Star Trek theming all over it and to the right of the menu were three detailed Megadrive styled sprites of Riker, Picard and Data (but no Geordi, which is odd considering he's one of the ships main engineers) over a black background with stars. also everything was purple for some reason. it was just. purple Star Trek.
there was also a bit where i looked up information about this old program and i found out that a variant of it appeared on very rare PS2 models and was built into the BIOs and would appear after a crash. i don't know why it was the PS2 specifically. it was probably because it looks like something that would be on there.
(also there was this other bit that happened in the dream that was really funny where, after my computer crashed again, a real life borg literally just appeared next to me and i turned to them and went "hey can you help fix my computer" and they were like "sorry i can only attach human dna to it :(". and then later Data himself appeared and tried to help fix it, but for some reason his words were really muffled and hard to hear and he eventually just phased out of existence while desperately trying to explain what was wrong with it. my computer was so busted that bro fuckin died)
20 notes
·
View notes
Anyways as I had previously mentioned about me going insane, Behold!
As I sorta lowkey mentioned in the posts about my new, properly compiled teeth, I wanted to give them to everyone and here it is! Or at least the first bit anyway.
Now this is my first REAL mod so do note:
Original shape data is technically not intact but vanilla customization does appear entirely unaffected. So your head wont be broken!
Doesn't play nice with sculpts ofc
Male Elezen using mouth 3 on any head will likely notice clipping despite repeated attempts to prevent this. I will try fixing it again at a later date
With that in mind, here's the link!
If you encounter any specific issues with it please let me know!
32 notes
·
View notes
Wrap030-ATX Remembers
No general-purpose computer will do much without a good amount of Random Access Memory for transient storage of code and data. Now that I have confirmed basic operation of CPU, bus controller, ROM, and serial, it's time to turn my attention to main system memory.
Every homebrew computer I've built to date, including previous iterations of the Wrap030 project, has used Static RAM. Static RAM is nearly as simple as peripherals can be — give it an address, assert a Chip Enable and a Read or Write strobe signal, wait a bit, and release. Done, cycle complete. If you don't need to retrieve some data for a good long while, it's no matter so long as the chip still has power. For a small system, SRAM is reliable and dead simple to use.
The problem with SRAM is it is also very expensive. The 2MB of SRAM I had on the previous iteration of Wrap030 cost over $20 — and it's still far from enough to run an operating system like Unix System V, NetBSD, Linux, etc. This is the reason computers generally use Dynamic RAM for primary system memory.
The difference is SRAM uses several transistors to create a flip-flop for storing each and every bit of memory, whereas DRAM uses a capacitor to store each bit of memory. This reduces manufacturing costs and increases storage density, but does come with some trade-offs. Most notably, the capacitors that store bits in DRAM will lose their charge — and the stored data with it — after a rather brief period of time. This means the DRAM capacitors need to be topped off regularly in a process known as a refresh cycle.
Another complication of using DRAM is the bus interface has been changed to allow much larger storage capacities without the physical chip package growing to absurd sizes. Instead of the chip accepting the entire address at once, it expects to be given a Row address (along with a Row Address Strobe [RAS#]) then a Column address (along with a Column Address Strobe [CAS#]), with myriad specific timing requirements for when each signal should be asserted and deasserted.
In short, DRAM is much more difficult to interface with compared to SRAM, so I've never really gotten around to it.
With one of the long term goals of this project being running a *nix operating system though, I'm going to need the larger memory that DRAM affords. So i made provision for a CPLD to serve as a dedicated DRAM controller on the Wrap030-ATX motherboard and added a couple 72-pin SIMM slots. In theory this setup should be able to support up to 256MB of RAM (if rare 128MB SIMMs should fall into my hands...).
So where do we turn when dealing with complicated timing with multiple modes and a bunch of I/O? Why, Finite State Machines, of course! That bit where the DRAM expects a row address for a little while, that's a state. And the following bit where the DRAM expects a column address is another state. And then another state to make sure the DRAM has enough time to write or fetch the data. The round it out with one last state to tell the CPU data is ready.
What about that weird refresh timing? Well, that's just few more states for the state machine. And then one last "idle" state that waits for a refresh timing counter to hit 0 or for the CPU to start a bus cycle. Laid out like that, the DRAM controller became a state machine with 7 or 8 states, a counter, and an address multiplexer.
The logic actually came together easier than expected. Not completely without bugs of course.
There's this note in the datasheets about startup initialization where the DRAM should not be accessed 200μs after power on, and there should be 8 refresh cycles before the first access. Initially I had built this entire sequence into my logic. It consumed a ton of resources and didn't really work right.
I realized that my reset circuit held the CPU in reset for longer than 200μs on power on, so I was guaranteed that first initialization time. So I removed that startup delay from my DRAM controller logic, and made a few tweaks to the state machine so it could do 8 back-to-back refresh cycles after reset.
I was able to successfully write to DRAM and read that data back!
That much proved to be the easy part. The next steps were confirming DRAM accesses worked reliably, that I had the order of my byte select signals correct, that I could identify the amount of installed memory, and that all of the installed memory was working. These are programming problems, not logic problems, and I am not a strong programmer. On top of that, not only am I working with unproven DRAM logic, but I'm also using untested SIMMs that I had picked up from Computer Reset.
I quickly ran into errors, but was it a problem with my logic? A problem with my timing? A problem with the SIMMs?
I had a large back of 72-pin SIMMs, split fairly evenly between Fast Page Mode (FPM) and Extended Data Output (EDO) types. I tried them all. Some would pass the tests for nearly all addresses but fail at the end. Some seemed to have a stuck bit. Some were just plain bad and gave errors everywhere. It didn't really answer the question about whether my logic was bad, but results were consistent enough for me to think that maybe the logic might be ok.
And then finally I came across a pair of HP-branded 8MB EDO SIMMs that passed a simple write-read test without error ...
... right around the time my serial port stopped working. But the memory test was passing, and I could at least see the serial output on the logic analyzer.
The serial port problem was a bit setback. It had been working but suddenly wasn't. Clearly the UART itself was working, I just wasn't getting anything past the level shifter. Well that at least gave me a starting point of where to look. Sure enough, one of the 12V supply pins was not well soldered. Thankfully a quick fix.
Back to testing memory, I started writing a program to identify the size of the installed SIMM and write a register I added to the DRAM controller to configure the specific geometry of the installed memory. See, DRAM has another lovely quirk — chips of the same size may have a different configuration of Row and Column sizes. For instance one chip may have a 9-bit Column and a 10-bit Row, but the next may have a 10-bit Column and a 9-bit Row, and both are the same size. If the DRAM controller just assumes 12-bit Row and Column (the largest supported by 72-pin SIMMs), then there will be gaps in the memory map that will need to be accounted for in software (using MMU, for example). If the DRAM controller knows the geometry of the installed memory, then it can present the memory to the CPU as one contiguous block of memory.
And that's where I found my next bug. The system would just hang when trying to write to that DRAM controller configuration register.
... because I had forgotten to complete that part of the state machine. The result was the state machine would end up in a state for writing to the configuration register, but then it couldn't get out of it. Once I added the missing condition to the state machine logic I was able to correctly identify the geometry and size for my installed memory!
Wow that was long. This has been the biggest, most involved step in the process of bringing up this computer yet. It turns out there are a lot of moving pieces that have to all work together to get the computer running code from ROM and reading/writing DRAM.
Now that I have my main memory working, I should be able to get some software running. I'm hoping to at least have BASIC running in time for VCFSW at the end of June.
33 notes
·
View notes