BMOW title
Floppy Emu banner

ADB-USB Wombat Manufacturing Trouble

Today I received a new batch of Wombat boards from my manufacturing partner. Too bad none of them work! Connected devices aren’t recognized, in either ADB or USB input modes. Oops.

After some lengthy investigation, I discovered that the main crystal oscillator speed on these new boards is about 3.69 MHz, but it should be 8.0 MHz. At 3.69 MHz the board will not work. But the oscillator seems to be an 8 MHz one (at least it has “8.0” in the part number stamped on it), and the associated capacitors and resistors measure roughly the same in-circuit values as a known-good board, so it’s unclear why I’m getting 3.69 MHz oscillation.

Problems happen, but this particular problem should have been caught by the testing procedure that I designed, before the boards were ever shipped to me. I re-ran the test procedure here, using a copy of the test harness that I previously gave to the manufacturer, and sure enough all five of the boards I tried failed the test. So either there’s some discrepancy between how I’m testing and how they’re testing, or they did the tests incorrectly, or didn’t run the tests at all.

The hardware and the test process are identical to the previous three Wombat batches made by the same manufacturer, but the person overseeing the project changed this time.

This is my nightmare scenario, and I’m not sure where to go from here. With some more bench time, I could probably determine exactly why the oscillation speed is 3.69 MHz. Perhaps these boards could be fixed with some hot air rework and component replacement, but who’s going to do that? I’m not about to desolder and replace crystal oscillators on hundreds of boards by hand, to fix someone else’s mistake. Returning the whole batch for rework in China would be prohibitively expensive in shipping and tariff costs. Even if the manufacturer agrees to stump for a complete re-do of the manufacturing, I’ll still be out roughly $750 for the cost of ICs I purchased and provided to them.

Read 21 comments and join the conversation 

Windows 10 Crashes Part 3 – New Clues

I’ve been struggling with unexplained Windows 10 crashes ever since I got a new computer in May. See part 1 and part 2 for the backstory. The symptoms were mysterious crashes and reboots that happened every day or two when I was not using the computer. From examining crash dumps and event logs, I found that most of the problems seemed related to the graphics display or window manager. I suspected that something about the computer’s handling of my external monitor was buggy – either in the Windows driver, the computer’s firmware, or the computer hardware itself.

I’m now more confident than ever that the external monitor is somehow causing the problem. On July 5, I swapped in a different external monitor and made a few other graphics changes, and since then I’ve gone 11 days with zero crashes or unexplained reboots. Unfortunately this new-and-stable config is not the config I actually want, so I still need to do more testing, but I think I’m getting close to a solution.

The computer is an HP EliteBook x360 1030 G2 laptop. It has a built-in 1920 x 1080 display. A second external monitor is connected by HDMI cable.

The crashes-every-day configuration was an ASUS PB258Q 2560 x 1440 monitor, connected with a no-name HDMI cable, and running at its native resolution. The Windows 10 Display control panel was set to “duplicate”, showing the same image on the external and internal monitor (scaled down). Scaling was set to 125% to make text more legible on the high-DPI external monitor.

The new-and-stable configuration is an ASUS VE228 1920 x 1080 monitor, connected with an Amazon Basics HDMI cable, and running at its native resolution. The Windows 10 Display control panel is set to “show only on 2”, effectively disabling the internal display. Scaling is set to 100%. Everything else is the same as before – same graphics driver version, etc.

Now I can do some A/B testing, and try to determine which of these differences is causing problems. Could it be something as stupid as a bad HDMI cable? Does the computer’s firmware not correctly handle scaling when the external monitor is a different resolution than the internal one? Could the 2560 x 1440 monitor actually cause crashes somehow, due to a bug in its firmware (I think HDMI is bidirectional) or electrical faults?

Read 5 comments and join the conversation 

Windows 10 Ongoing Crashes

My new computer continues to experience unexplained freezes and reboots, and I’m running out of ideas for fixing it. A few weeks ago I wrote about crashes in the Intel integrated graphics driver, and the symptoms have since changed, but problems continue. I’m now looking at either

  1. reinstalling Windows and all my applications, which would be a huge undertaking and might not fix anything
  2. replacing the whole computer and reinstalling all my applications, which would also be a huge undertaking
  3. resigning to accept a computer that can’t go more than a few days without crashing.

My previous Windows 7 computer easily ran for weeks without trouble, so this kind of instability is disappointing.

The new computer is a Windows 10 laptop (HP Elitebook x360 G2 1030). I use it with the lid closed, connected to an external monitor, keyboard, and mouse. I suspect this is the root cause of my problems. While this setup should work and does work most of the time, running a laptop with the lid closed doesn’t seem 100% robust. The computer sometimes seems to lose communication with the external monitor, or gets confused because the primary (internal) monitor is off. I see occasional event log entries like “A pointer device has no information about the monitor it is attached to”, window manager crashes, and other graphics related errors. And all of these problems happen while I’m away from the computer, when the external monitor is in power-save mode, but the computer is not asleep. When I return to the computer later, I sometimes find that it has frozen or unexpectedly rebooted.

I should emphasize that the computer rarely sleeps and never hibernates, so I don’t believe this is a sleep-related problem.

 
History

The first problem was crashes in the Intel integrated graphics driver igdkmd64.sys while I was away from the computer. Nearly every day, I’d return to the computer in the morning to find that it had crashed and rebooted sometime since its last use. Here’s what’s happened since then:

June 15 – I forced an update to the latest Intel graphics driver version 26.20.100.6890. This required completely uninstalling the HP-provided graphics driver first. Since then, I have not seen any more crashes in igdkmd64.sys.

June 16 – The computer was still running since the day before, but the Start menu and Cortana did not work. I restarted the computer and Start/Cortana began working normally again.

June 17 – The computer fan was blowing 100%, but both the external and internal screens were dark. I could tell that Windows was still running, because I heard the Windows disconnection sound effect when I unplugged USB devices, but nothing I did would get an image to appear on any screen. I forced a reboot with the power button. The event log showed several prior errors about the embedded controller (EC) not responding. In light of this, I disabled the 3rd-party program Notebook Fan Control. After rebooting, the computer hung on the boot screen with the HP logo, and did not proceed into Windows. After rebooting a second time, all seemed normal.

June 18 – The computer was still running since the day before, but once again the Start menu did not work. I used the task manager to terminate WindowsShellExperienceHost.exe, which then automatically restarted and restored normal Start menu functionality. Afterwards I fully uninstalled Notebook Fan Control. Following a tip related to broken Start menus, I also turned off the Windows option for Settings -> Accounts -> Sign in Options -> Use my sign-in info to automatically finish setting up my device and reopen my apps after an update or restart.

June 19 – All OK. The computer was still running since the day before, with no problems.

June 20 – All OK.

June 21 – All OK.

June 22-23 – Didn’t use the computer.

June 24 – All OK.

June 25 – The computer was still running since the day before, but again the Start menu did not work. I terminated WindowsShellExperienceHost.exe to get the Start menu working again.

June 26 – All OK.

June 27 – Didn’t use the computer.

June 28 – The computer fan was blowing 100%, but both the external and internal screens were dark. Nothing I did would get an image to appear on any screen. I had to hold the power switch to reboot the computer. The event log showed lots of errors in the preceding hours, including multiple desktop window manager crashes, and an application hang error from Microsoft.Photos.exe every 15 minutes stretching on for hours, all during a time when I wasn’t using the computer.

June 29 – The computer fan was blowing 100%, but both the external and internal screens were dark. Nothing I did would get an image to appear on any screen. I had to hold the power switch to reboot the computer. Nothing interesting was found in the Windows event log.

I don’t understand what’s going on here, but it’s a hot mess.

Read 16 comments and join the conversation 

Introducing Noisy Disk

Do you miss the iconic sounds of mechanical click-clacking from original Apple II floppy drives? Does the familiar rattling of a boot floppy bring a smile to your face? Today I’m introducing a new product called Noisy Disk. This board uses a mechanical relay to create authentic-sounding disk head movements for the BMOW Floppy Emu disk emulator. Sure it’s useless, but it’s useless fun.

The Noisy Disk board attaches inline with your existing Floppy Emu cable, using the provided 6-inch extension cable. When Floppy Emu is configured to emulate a 5.25 inch Apple II floppy drive, the Noisy Disk onboard relay snaps open and shut whenever the emulated disk steps from one track to the next. It creates a symphony of disk noise that will bring back memories of 1979.

Noisy Disk is compatible with Apple II family computers while using Floppy Emu in 5.25 inch emulation mode. Nothing will be harmed if Noisy Disk is used with other computers or emulation modes, but you’ll hear strange clacking noises that don’t match the disk activity. It’s recommended to use Noisy Disk in 5.25 inch emulation mode only.

The product includes the Noisy Disk board with 2 x 10 pin rectangular input and output connectors, and a 6-inch extension cable for connecting to your Floppy Emu board.

Noisy Disk is available now at the BMOW Store.

Read 6 comments and join the conversation 

USB Wombat Parts Shortage

I’m forecasting an extended out-of-stock period this summer for the Wombat ADB-USB Keybord/Mouse Converter. One of the Wombat’s parts is currently out of stock everywhere, and the manufacturer is advertising 16 weeks lead time for delivery of more parts. There are still enough Wombats on hand to cover a few more weeks of typical sales volume, but then it will probably be October before more are available. If you’ve been considering getting a Wombat, you should order it now or be prepared to wait until autumn.

The Wombat is a bidirectional ADB-to-USB and USB-to-ADB converter for keyboards and mice.

  • Connect modern USB keyboards and mice to a classic ADB-based Macintosh, Apple IIgs, or NeXT
  • Connect legacy ADB input hardware to a USB-based computer running Windows, OSX, or Linux

No special software or drivers are needed – just plug it in and go. Now you can finally use a modern optical mouse with your vintage Macintosh, or amuse your coworkers with a retro ADB keyboard on your work machine. ADB-USB Wombat is an indispensable tool for Apple collectors and enthusiasts.

Read 2 comments and join the conversation 

Intel Integrated Graphics Driver Crashes

Here’s a mystery for Windows-lovers (or haters) – unexplained crashes in the Intel integrated graphics driver whenever the computer is left unattended. A few weeks ago I upgraded to a new PC, choosing an HP Elitebook x360 laptop that’s mainly used in a desk-bound docked mode. This computer is running Windows 10 Pro with whatever drivers HP saw fit to preinstall. The mystery began shortly after the new computer was put into service. When I’d sit down at the computer in the morning, I’d find a log-on screen and a blank desktop. All the programs and documents that I’d left open from my previous session were gone. Why?

 
Hunting the Cause

My first thought was to suspect Windows Update. Probably it was downloading and installing updates overnight, rebooting the computer afterwards. That would be annoying, but at least it would be explained, and wouldn’t happen too often. But the problem reappeared every day or two over the next week, sometimes even happening twice in the same day. I never witnessed the update reboot happening (or whatever it was), but when I’d leave the computer unattended for a couple of hours or overnight, I’d often find an empty desktop when I returned.

Eventually I thought to check the Windows event viewer (Control Panels -> System and Security -> Administrative Tools -> View Event Logs). Here I found symptoms of a very different problem than I’d imagined. The computer was frequently crashing and rebooting whenever I was away:

The same sequence of errors appeared five times over the last week, at seemingly random times of day: 9:25 AM, 5:25 PM, 1:26 AM, 8:21 AM, 12:57 PM. This doesn’t obviously fit with my usage of the computer. Some of the crashes happened an hour or two after I last used the computer, other crashes were 12+ hours after. The times also don’t seem to fit with any background task that I can identify.

I installed the program BlueScreenView to examine the crash dump files referenced in the BugCheck entries of the event log. Each crash dump appears to overwrite the previous one, so I was only able to example the most recent crash. To further complicate things, Windows appears to periodically delete the crash dump files according to some schedule I haven’t determined. But I was able to catch and examine several crash dumps over a few days, and all of them showed the same culprit. It was an error 0x0000007e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) in igdkmd64.sys. A quick Google search revealed that igdkmd64.sys is the Intel integrated graphics driver for recent CPUs with built-in graphics hardware.

 
No Driver Update for You

My first thought was to update the graphics driver. Maybe the crash was caused by some bug that’s fixed in the current version. I visited the Device Manager and tried to update the driver there, but was told my driver version 25.20.100.6472 from December 2018 was already up to date.

Skeptical, I visited HP’s support site and confirmed that the latest driver version there is the same 25.20.100.6472. Then I visited Intel’s site to search for the driver, and discovered that the current version is 26.20.100.6890 and was released just two weeks ago on May 29. Aha! I downloaded the driver and attempted to install it, only to be denied:

It seems I had a special HP-customized version of the Intel graphics driver already installed, and the generic driver installer refused to replace it. Some more web searching suggested that it was almost always safe to ignore this and install the generic driver anyway, using the Device Manager to directly select the driver’s INF file rather than using the driver installer. But I was denied there too. Intel recently switched to some new type of driver installation that’s not backwards compatible with previous drivers, and they explicitly warn that bypassing the installer by manually choosing the INF will result in “minor to catastrophic” issues on your computer. Here’s the full text:

Important Note:

These new drivers labeled as Windows DCH graphics drivers are not backward compatible with our previous graphics drivers that we’re now labeling Legacy. This means if later you want to revert to a Legacy driver you will need to uninstall the driver via Windows Apps and Features and reboot the system before installing a Legacy driver. Failure to do so may result in minor to catastrophic issues on your system as well as system instability.

DO NOT use the INF / Have-Disk method to install or uninstall this driver as it bypasses the Intel installer designed to install these new drivers, thereby possibly resulting in minor to major system instability. For this reason, we’re not providing the ZIP file for the next several driver releases while users transition to this new Microsoft driver platform.

There’s probably a way to circumvent this and install the driver anyway, but since I have no specific reason to believe it will fix my problem, and Intel has warned me not to do it, I’m going to leave it as is.

 
Idle Speculation

That leaves me with unexplained system crashes without any obvious solution. But given the type and timing of the crashes, I can speculate about the possible cause.

The crashes always occurs when the computer is unattended, never (so far) while I’ve been using it. That suggests a problem related to sleep/wake, or else with some background process that only runs when the computer is idle. But the computer isn’t sleeping, or at least it shouldn’t be. The sleep timeout is set to 18 hours, and that seems to be working correctly. I don’t think the computer is sleeping or waking when these crashes occur.

The rather strange number of 18 hours was chosen to accommodate my backup software, Paragon Hard Disk Manager 16. It’s configured to do an incremental backup to an external USB drive every night at 12:30 AM. It’s also configured to wake the computer from sleep, if necessary, to do the backup. But I found that wake from sleep didn’t work, and if the computer was asleep at 12:30 AM, the backup wouldn’t happen. By extending the sleep timeout to 18 hours, it ensures that I’ll get a backup at 12:30 AM if I used the computer any time after 6:30 AM the previous day. That’s about right for my usage. These mystery crashes started at roughly the same time as when I installed the Paragon backup software, so maybe that’s a clue, or maybe it’s just coincidence.

The second detail of these crashes is that they’re in the graphics driver, so presumably they’re somehow graphics-related. This is a laptop computer used as a desktop, so the laptop normally has its lid closed and its built-in screen disabled, while I work with an external monitor, keyboard, and mouse. This isn’t exactly a rare setup, but it’s not the most common configuration either, and maybe it’s somehow contributing to the problem. I could try leaving the computer with the lid open for a while to see if that helps, but it’s not really how I wish to use the hardware.

There’s one more clue to consider. Also in the event log, I found many entries related to a problem with gfxdownloadwrapper.exe. I couldn’t find much information about this program on the web, but it appears related to Intel graphics drivers somehow. These errors first appeared on May 29 and the last one was on June 8, but the mysterious igdkmd64.sys crash has happened three more times since then.

The gfxdownloadwrapper problem is related, perhaps, but not a direct cause. For now this will remain a mystery, and an advertisement for why people dislike Windows.

Read 14 comments and join the conversation 

« Newer PostsOlder Posts »