We conclude our series by stepping back from the gates and transistors to look at the Lifecycle of the Embedded System. In a world of software-defined hardware, a product …
-
-
In the early days of embedded systems, hardware was “thrown over the wall” to firmware engineers. The silicon was fixed, and the software was expected to work around its quirks. …
-
As we move toward “Always On, Always Connected” systems, a new category of debugging has emerged: Connected Standby. Bug Check 0x15F: CONNECTED_STANDBY_WATCHDOG_TIMEOUT is the modern version of the power state …
-
Not all BSODs are caused by a “bad line of code” in a driver. Sometimes, the system crashes because a vital organ of the OS—like the System Registry or a …
-
While many BSODs happen purely in the “dark” of the kernel, Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION occurs at the boundary where a user-mode application makes a request to the kernel (a …
-
For those working in the semiconductor and systems space, many BSODs aren’t caused by a software logic error, but by a breakdown in the communication between the CPU and the …
-
While we’ve spent a lot of time discussing the Kernel Pool (the heap), there is another critical memory area that is much smaller and far more dangerous: The Kernel Stack. …
-
In our previous articles, we covered timing and resource deadlocks. Now, we return to the most frequent “bread and butter” of Windows debugging: The Access Violation. When a driver tries …
-
In our final installment of this introductory series, we move from runaway loops to the opposite problem: The Deadlock. This is where the system isn’t “busy”—it’s “stuck.” Two or more …
-
In the semiconductor and hardware world, timing is everything. While previous articles focused on memory safety, this one deals with responsiveness. The Bug Check 0x133: DPC_WATCHDOG_VIOLATION occurs when the system …
- 1
- 2