Windows ME BSODs (Exception, System Busy, and WARNING) Captured directly from VMware Workstation today.
I had found in the past that it was a bit hard to find clean, unedited, pixel-perfect copies of the Blue Screens of Death, so when my Windows ME VM crashed today I knew it was time to save these for the future. These are pretty much the same as the ones that would appear in Windows 95 and Windows 98.
First the classic “An exception 0D has occurred” BSOD
Next, System is busy
and last but not least, WARNING system has become unstable
Installed a new Ubiquiti USG at an office downtown today, and noticed that in the 8 hours since the system was first up, it had detected over 800 nearby networks. I decided to analyze the data a bit for fun.
First, the channel. I was surprised to see that over half of all detected APs were on channel 6.
It does make sense that there are far more 2.4GHz APs detected, since it has better signal penetration.
Next up, security standards.
Nearly 90% of APs are using WPA2 of some sort, and just over 10% are open. Less than 1% use WPA.
Now, arguably the most interesting – the AP manufacturer, according to OUI lookup.
Note: some OUIs were not recognized, so the dataset is slightly less than 800 here.
In the manufacturer breakdown we se a lot of the usual brands – Cisco, Aruba and Ubiquiti are in the top. Technicolor, Sagemcom, ASUS, HP, Juniper, Sonicwall are all also common network vendors. But what of the others?
The biggest “unusual” vendor we see is Mitsumi. Mitsumi is generally known as an OEM that manufactures PC peripherals and input devices – mice, keyboards, floppy and optical drives, and quite a few game consoles. It’s not surprising that they would make WiFi radios, but I wouldn’t expect their OUI to be used as an OEM.
Looking a bit further at the data, most of the Mitsumi networks’ SSIDs are in the format “WiFi Hotspot 0000” (where 0000 is a random 4 digits). However, a few of them had names such as “Cruze”, “Volt”, “Equinox” and “Malibu”. So, apparently Mitsumi manufactures the WiFi radio for the GM OnStar car hotspots.
Continuing on with the less-known OUI vendors, we also see Visteon, Continen (Continental), Harman/B (Harman/Becker), and AlpsElec (Alps Electric).
Alps, like Mitsumi, is an OEM known for PC peripherals – particularly keyboards and laptop touchpads. In this case, the SSIDs for the Alps APs are all some variant of “MB Hotspot 000” – so they are Mercedes-Benz car hotspots.
So, unsurprisingly, the other 3 are also car electronics OEMs.
Visteon – spun off from Ford in 2000, they specialize in car infotainment and other electronics systems. Continental Automotive Systems – The electronics systems branch of German company Continental Tire. Harman/Becker – a division of Samsung, specialized in car electronics, resulting from the Harman company’s acquisition of Becker, a German car radio manufacturer.
Today’s takeaway: a LOT of cars have WiFi hotspots built-in these days!
Got frustrated that this form wasn’t available as a proper PDF form, so made it myself. Intended only as a convenience for those who wish to use it. PDF is not password-protected or signed.
Download a copy of the 4383-80E pdf form (Patient Enrolment and Consent to Release Personal Health Information) below.
Update: Even after doing all this the system still locks up randomly when using the amdgpu driver.
I’m running dual AMD FirePro W2100 driving 3 monitors in my workstation. Since installing the cards I’ve been suffering random freezes/graphical lockups that seemed to be related to 3D. They occurred typically during an animation in gnome-shell, or when using Firefox or Chrome with hardware acceleration. Most times, I was able to recover by logging in to the machine via ssh and sending killall -HUP to the appropriate process (usually gnome-shell). Every time this happened, syslog would be full of GPU faults:
I tried updating my kernel (going from Ubuntu 18.04 to 18.10 and even reinstalling with Pop!_OS 18.10 than 19.04) and updating graphics drivers using the oibaf ppa, to no avail. Finally found what seems to be the solution on HackerNews (thanks danieldk) – force the use of the newer amdgpu driver rather than the older radeon driver. The W2100 is a first-generation GCN chip and so is supported by both drivers, and radeon is chosen as the default. To force amdgpu, you need to pass the kernel flags
In Ubuntu, add these to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then run update_grub. Pop!_OS doesn’t use grub, so you need to add each flag using kernelstub -a amdgpu.si_support=1 and repeating for each of the 4.
So far, my system seems stable since this change. I will update this post if anything changes.
Oracle have decided to disable access to Java apps that use MD5withRSA signatures. For instance, when launching the .jnlp file to connect to my Lantronix Spider remote KVM, I am presented with this error:
To fix this, we have to change Java’s security settings. Unfortunately, settings for signature algorithms are not in the Java Control Panel, so we have to edit the config files directly.
On macOS, the default JRE installation’s root directory ($JAVA_HOME) is
where “1.8.0_131” is your specific Java version, and on Linux, JRE is installed in
/usr/lib/jvm/java-1.7.0-openjdk-amd64
once again where “1.7.0-openjdk-amd64” is your specific Java version.
In the JRE directory, we then need to edit the file
$JAVA_HOME/lib/security/java.security
and comment out the line that starts with “jdk.jar.disabledAlgorithms” by prefixing a #. Note that this will allow jar files signed with any algorithms to run, which can be considered insecure.
After installing Wine in Ubuntu Gnome 17.04, I noticed that double-clicking on .exe files in Nautilus still opened them in Archive Manager. I tried the usual right-click > Properties > Open With, but Wine was not listed as an available option.
It turns out that in the Wine package for Ubuntu 17.04, the wine.desktop file is not created in /usr/share/applications, and so does not show up in the Gnome GUI. To make things work, we need to copy the wine.desktop file from /usr/share/doc/wine-stable/examples/ to /usr/share/applications/
When setting up Postfix on Ubuntu/Debian as “Internet Site with smarthost” to use an external smtp relay, automatic e-mails intended for “root” (such as cron job error reports) get sent out to the smarthost with a To: address of [email protected] This can cause a problem as the smarthost doesn’t know where to deliver these messages to, since myhost.mydomain.com has no MX record.
A drawback of sending mail as “[email protected]” (instead of “[email protected]”) is that mail for “root” and other system accounts is also sent to the central mailhost. In order to deliver such accounts locally, you can set up virtual aliases as follows:
It’s really cool what we can do with computers these days. I generally take technology for granted, but sometimes I am just in awe of what is possible.
With the ubiquity of the Internet
It’s all too easy to forget
How amazing it is, that with relative ease –
Just a few strokes of the keys
A sysadmin can ssh to a box running Unix
On the other side of the world, or just across town.
And with just a few clicks
Bounce that Windows box that’s gone down.
Comments (0) 
Themocracy