Hacking A Quantel Dylan Disk Array

I have recently been working on a Quantel HAL video compositing system as featured on my last post.

While i have been trying to diagnose all it's faults i discovered a rather annoying feature of the Dylan disk array that stores the video clips.

The array is a 6U chassis that contains three PCBs with a controller CPU and 20 SCSI disk controllers to operate the 20 Fujitsu hard disks.

During my work the Dylan flagged up one of the disks had failed but continued to work, shortly after it then flagged another and disabled video from the array.

Once this happened i tried replacing a disk only to be met with a 'disk serial changed' message, i tried swapping the replacement disk into one of the slots for a working disk which generated another disk serial changed error and the array now had three drives that were not working.

At this point i realised that either the host system (Quantel HAL) or the array was keeping a track of the disk drive serial numbers and preventing replacement of the disks. After some investigation i found no details of the disk serial numbers within the HAL operating system so looked at the array itself.

The CPU on the array is an Inmos / ST Micro IMST425-G25. This is a 25mhz Inmos 'Transputer', further examination of the control board didn't show up any EPROM for holding the program for this CPU but it did show up an Inmos link IC. The link IC allows a host to load CPU code over a serial link through the CPU to RAM and then start the CPU. Basically meaning the code is loaded remotely by the HAL.

So there was no EPROM or battery backed SRAM on the controller, the task now was to find where the serial numbers were stored.

After careful examination of the board i found a Atmel 24C02 serial EEPROM. This was de-soldered using hot-air, mounted into a test clip and read out using a TL866 EPROM reader/programmer.

Immediately it was clear it contained the serial numbers of the disk drives with three of them containing zeroed serial numbers, very likely the three drives that had been flagged up previously. The remaining serial numbers were exact matches for the serial numbers printed on the physical disks.

From here it was a simple task to add the missing and new serial numbers into the EEPROM and reprogram it. I also added a plug in board to allow this to be done easier next time.

It's highly likely that Quantel engineers had a tool to program in new serial numbers into the array through a 10 pin header located on the PCB.

Quantel HAL Video Compositing System - Introduction

The Quantel HAL is an evolution of the V-Series architecture that Quantel introduced in the late 1980s as used originally on the 2nd generation Paintbox, it expands on it with upto 18 plugin expansion cards on it's expanded backplane (Hiway as Quantel call it) housed in a 6U chassis.

The Quantel HAL system is a video compositing system that can composite upto 99 'layers' in a single pass. Layers would be static images, video clips or stencils (masks) that can all be manipulated in a 3d space along with various effects that can be applied. Video storage is on a separate 'Dylan' disk array connected via a proprietary interface and contains 24gb of disk storage to give a total of 15 minutes of uncompressed standard def PAL/NTSC video.

In many ways it's similar to the Quantel Harriet, which is a combination of a Paintbox and Ramcorder. The Harriet is designed for compositing static pictures and animation on top of video and is limited to 323 frames in the Ramcorder. The HAL differs in it has far greater storage and can composite video on video with key (stencil) channels on any of the 99 layers.

The user places video clips, pictures and stencils onto a keyframe timeline to create a sequence of effects which are then rendered out to a new clip or composited over the top of an existing clip.

The main chassis contains two hard disks, a system boot disk and a shared disk. The boot disk contains all the software and local files, the shared disk contains all the network shared files. This setup is exactly the same as the Paintbox. There are 4 SDI video inputs and outputs, 1 (stereo) digital audio input and 2 outputs along with an analog 'broadcast standard' video in/out.

Side View of the HAL showing all the cards.

The PSU and two hard disks are mounted in the top.

The Dylan disk array contains 20 fujitsu 1.2gb 3.5" SCSI disks each with it's own SCSI controller a lot of logic and a small Inmos/ST transputer CPU to look after the array. There is no CPU code stored on the array as it's loaded over a dedicated 'inmos link' when the main system boots. The array CPU simply looks after errors from the disks. From what i understand the HAL writes video round-robin to the disks. There is ECC so the data on a failed drive can be rebuilt once it's replaced. The array also stores the disk serial numbers of the drives in an EEPROM to prevent user-replacement of the disks. If a disk is changed the system will flag the disk and stop using it. Once two disks are either flagged as serial number changed or have found to be faulty the array will go offline and the user is unable to have access to video on the HAL. The capacity of the array is determined by the software keys on the HAL system, so probably all disk arrays had 24gb but depending on how much ££ you paid quantel you could have access to 5, 10 or 15 minutes of video.

Top view of the Dylan 2 disk array. The Inmos CPU is in the top left corner, PSU in the middle and the SCSI controllers around the edge with the cables running to the disks.

HAL System cards:

The HAL contains the usual 3 cards found in any v-series system. CPU, Mainstore, Diskstore and some kind of image processing card like is found in a Paintbox. So this could be Size, Rotation, Perspective, CAP (Contour and Perspective) or Image. With Image being the most advanced.

CPU: Quantel's standard CPU42 board with 64mb RAM & 68040 CPU.

Netcomm: Quantel's standard netcom board, 68000 based network interface.

Input Select: Analog video input processing card and digital video input (the actual digital input decoding is processed on a smaller board located in the top of the chassis).

APE: Audio processing card.

Image: Essentially a software CPU / processing engine based on a large quantity of altera CPLDs and an Inmos/ST Transputer CPU, provides all the processing for image transforms (size, rotation, 3d effects etc).

Diskstore: Regular diskstore card.

Mainstore: Regular mainstore card.

Output Select: Analog video output processing & digital video output (the actual digital output decoding is processed on a smaller board located in the top of the chassis).

Mux: interface to the dylan disk array.

Disk Link: I think more disk array interface stuff.

Router: I think this does some switching of video to/from the disk array.

Key 2: lots of logical processing on this card, going by it's name it must be something with video keying.

Vid Proc 2: like Key 2 this has lots of 'bit-twiddling' ICs for image processing.

Inside A Toyota GT86 Ignition Coil Pack

Some pictures of the insides of a Toyota Ignition Coil Pack from a Toyota GT86.

This particular coil pack failed which seems to be a common problem on the GT86. I decided to see how they are constructed to see if there was any sign of why this one failed.

It sat in Dichloromethane for about two months to remove the potting compound and plastics. Occasionally i would take it out and remove some of the softened plastic and immerse it again.

Although the depotting process has caused significant damage to it we can see the major components.

A coil pack is basically a pulse transformer, there is an iron core with the high voltage secondary coil wound around and separated into sections, this is to provide isolation between the sections of the coil as the coil will generate many 10s of kilovolts. The primary winding can't really be seen but the thicker gauge wire is visible slightly at the top connected to the outer most conductors at the top.

Also visible is a diode and under the main connection terminals is the driver IC (a black rectangle) which has four connections. These connect to the external 3 contacts which provide GND, +12v and Trigger inputs, the fourth connection on the IC is the other side of the primary winding.

The spark plug connection has departed from the secondary coil as it was connected only to the fine wires of the secondary, it fell off during the depotting process.

Interestingly the driver IC does seem to be cracked, it's not clear though if this was caused by me during depotting or if it is the cause of the coil pack failure.

The coil pack before depotting.

The three external connections are on the right, with the driver IC just under them.

View of the high voltage secondary.

Top view showing the external connections and the IC underneath.

Teardown: Photec IV - 20,000 FPS 16mm Film Camera

In this video i take a look inside a 1980s film camera capable of 20,000 FPS.

The Photec IV camera was introduced in the 1980s by Photonic Systems Inc, It is a high speed 16mm movie film camera that uses a rotating prism to allow the film to run through the camera in a continuous motion.

The camera can take 400 ft film loads and has a Mamiya 645 lens mount.

The camera was available in different configurations, different prisms could be installed for full frame, half frame and quarter frame shooting which multiplied the FPS by x1, x2 and x4. The configuration on my camera is half frame.

The camera has a configurable FPS from 100 to 1000 FPS in 100 FPS steps and 1,000 to 10,000 FPS in 1,000 FPS steps at full frame. In half frame configuration this is 200-20,000 FPS and quarter frame is 400-40,000 FPS.

Mechanically they are quite simple, a large motor drives the take up reel, the action of the film running through the sprockets drives the prism.

At 10,000 FPS the linear film speed is around 170mph.

Reading Unsupported PROMs On A MiniPro TL866

As part of our slow progress with the Quantel DPB-7001 Paintbox we have been working a way to try and emulate a SMD hard disk. Because we don't have a working DPB or an SMD drive we need to build a rudimentary emulator of the disk controller element of the DPB so we can understand how it works.

Quantel DPB-7001 Disk Sequencer Card with 7 PROMs on the far right.

This will allow us to design a replacement plugin card for the physical DPB-7001 that would replace the Disk Sequencer card with a SMD emulator built into it using some flash memory and an FPGA.

Although most of the DPB uses standard 74 series logic, the disk controller uses an AMD AM2910 microcode sequencer driven from a small set of codes contained within 7 PROMs. We need to extract the code from these to be used within the DPB emulator that is being written. These PROMs are 28L22 devices with 256 x 8 bits of storage. The addressing is simple for these devices, there are 8 address lines to address each of the 256 memory locations and 8 data bits of output.

Unfortunately my MiniPro TL866 EPROM programmer doesn't support the 28L22, but that does not mean it can't read them with a bit of thought.

What we can do is make a small adaptor board to convert the pinout of the 28L22 PROM to be pin compatible with some other memory device the TL866 can read.

The closest match i could find was the AM2716B, which is a EEPROM with 2048 x 8 bits of storage. Though this has 10 address lines to access the additional memory space of this device. This is not a problem, we can simply leave these two extra address lines unconnected at the reader. The result of this is the reader will think it's reading out 2048 bytes of data but in fact it will be reading 256 but it will wrap around 8 times in the data readout.

Firstly we need to make an adaptor board to connect the device into the TL866:

During construction, the pin headers protrude through the base of the strip board to make contact with the ZIF socket of the TL866. Each pin can then be wired to a IC socket the 28L22 PROM will plug into.

View from underneath.

The 28L22 PROM plugged into the TL866.

Once the data is read out, we simply discard the last 1792 bytes of data to get to the original 256 bytes of data.

Quantel Schematics & Documentation

During my adventures with the Quantel Paintbox i have unearthed several pieces of documentation that i have scanned in and provided on my Google Drive for all to access.

Many Quantel products used the 3U V-Series chassis so these documents maybe of relevance even to non Paintbox systems. For example the Editbox used the same architecture as the V-Series but was in the larger rack.

As i add more i will include the details into this post

To access the repository use this link:

https://drive.google.com/drive/folders/0B24DgvumEJXiSndSVU1UVFhNTWc?usp=sharing

The current list of documents is as follows:

Quantel BridgeProcessor2 2058-66 Schematic.pdf

Schematics for the Bridge Processor used in the V-Series chassis.

Quantel CPU3 2060-74 Schematic.pdf

Schematic for the 68010 CPU3 (2060-74) card used in the early V-Series chassis.

Quantel CPU42 2078-82 Schematic.pdf

Schematic for the 68040 CPU42 (2078-82) card used in the later V-Series chassis, similar 2099 & 2101 boards were also used in the Editbox, Domino systems that used the same architecture.

Quantel DiskStore1M 2060-72 Schematic.pdf

Schematic for the DiskStore1M (2060-72) card used in many of the V-Series chassis.

Quantel VideoOut4 2057-69 Schematic.pdf

Schematic for the VideoOut4 (2057-69) used in some of the V-Series chassis, this has YUV/RGB analog and SDI digital output.

Quantel Netcom & Snetcom Documentation.pdf

Some possibly internal user guide for the Netcom and Snetcom board used in the V-Series chassis.

Quantel Network Engineering Training Manual 2066-58-050B.pdf

Network Engineering Training Manual 2066-58 for the V-Series including details of picturenet etc.

Quantel Paintbox Express Installation Manual 2090-58-030B.pdf

Complete installation manual for the Paintbox Express, this is a later 68040 based V-Series machine.

Quantel Paintbox Maintenance Training Manual 2056-58-050C.pdf

Some maintenance & engineering information for the V-Series Paintbox.

Quantel Picturebox Maintenance Training Manual 2057-58-050C.pdf

Similar to the manual above but for the V-Series Picturebox.

Quantel Paintbox V-Series - Setting The RTC Date

EDITED 25-10-2017: Since this was written i have found there are built in commands for setting the RTC located in the diagnostics console at \FILER\UTILITIES\TIME. However the details here still apply if you wish to set the RTC manually. Note the RTC located on Netcomm or Snetcomm boards is located in a different memory location (base at $F30000) but operates in the same way.

I have recently been playing around getting a Quantel Paintbox (V-Series Harriet) running. During the process i had to replace the battery backed SRAM which also contained the Real Time Clock (RTC).

Within the Paintbox user interface there is an option to set the time but not the date, this is even true in the engineering console where you have more access to the operating system. The only way to set the date is to manually set the RTC clock by poking bytes into a memory location.

This is due to Quantel's time-limited software keys. If there was an easy way to set the date then it would be easy to circumvent their feature expiry time by simply adjusting the system date before the key expires.

The V-Series CPU3 (also CPU3, CPU42 & CPU43) board has two battery backed SRAMs, these are the ST MK48Z02 and the MK48T02. The 'Z' version is a regular SRAM, the 'T' version includes a RTC which is mapped into the last 8 bytes of the MK48T02's 2048 byte address space.

In the CPU3 implementation 'RF' (the component designation on the PCB silkscreen) is the MK48T02 and 'RD' is the MK48Z02. Both devices are memory mapped into the 68000 address space starting at $040000 to $040FFF. The MK48Z02 is mapped to EVEN bytes and the MK48T02 is mapped to ODD bytes to give a total capacity 4,087 bytes (accounting for the 8 RTC control registers).

According to the datasheet for the MK48T02 device the RTC register map is as follows:

Add  D7 D6 D5 D4 D3 D2 D1 D0
7FF:  -  -  -  -  -  -  -  - : Year 00-99
7FE:  0  0  0  -  -  -  -  - : Month 01-12
7FD:  0  0  -  -  -  -  -  - : Date 01-31
7FC:  0 FT  0  0  0  -  -  - : Day 01-07
7FB: KS  0  -  -  -  -  -  - : Hours 00-23
7FA:  0  -  -  -  -  -  -  - : Minutes 00-59
7F9: ST  -  -  -  -  -  -  - : Seconds 00-59
7F8:  W  R  S  -  -  -  -  - : Control

ST=Stop Bit
R=Read Bit
FT=Frequency Test
W=Write Bit
S=Sign Bit
KS=Kick Start Bit

To translate this to the Paintbox memory map we must multiply the address by 2 and add $40001. So the map becomes:

Add    D7 D6 D5 D4 D3 D2 D1 D0
40FFF:  -  -  -  -  -  -  -  - : Year 00-99
40FFD:  0  0  0  -  -  -  -  - : Month 01-12
40FFB:  0  0  -  -  -  -  -  - : Date 01-31
40FF9:  0 FT  0  0  0  -  -  - : Day 01-07
40FF7: KS  0  -  -  -  -  -  - : Hours 00-23
40FF5:  0  -  -  -  -  -  -  - : Minutes 00-59
40FF3: ST  -  -  -  -  -  -  - : Seconds 00-59
40FF1:  W  R  S  -  -  -  -  - : Control

You can poke bytes into these addresses using the Quantel AFS Monitor on the serial port prior to booting the Paintbox software or you can use the 'MEMORY' command from within the Paintbox console.

Using the AFS Monitor to set the date to Wednesday 7 December 2016, remembering the values are BCD and the year is defined as years since 1980.

At the command prompt:

Allow write access to registers & stop clock:

40FF1;80

Set the day of week:

40FF9;03

Set the date:

40FFB;07

Set the month:

40FFD;0C

Set the year:

40FFF;36

Disable write access to registers & start clock:

40FF1;00

Teardown: AMO Sovereign Phaco - Cataract Surgery Machine

In this teardown i look at a AMO Sovereign WhiteStar Phaco machine used to perform cataract surgery.

'Phaco' is a short form of Phacoemulsification which uses an ultrasonic knife to cut into the eye and chop up the damaged lens into small pieces soa new artificial lens can be inserted.

The machine i acquired was used in a local vets almost complete but with without the ultrasonic hand tools. Probably they kept them as spares for their new machine which replaced this one.

The machine is made up of a steel and aluminium chassis and the control box mounted on the top. Inside the chassis is an air pump, motorised IV pole, printer, storage tray and the along with the foot switch a few other electrical cables and power distribution.

The main controller is made from a steel outer chassis with plastic coverings. Mounted on the front is a LCD screen and control buttons. Inside the controller is a switch mode power supply, Ziatech embedded computer, phaco and diathermy power control board, parastaltic pump and valve arrangement and a SCSI solid state drive which contained the operating program.

The embedded computer is a Ziatech Z200, this uses a 80486DX4-100 CPU with 8mb RAM with several option boards; SCSI 2 Interface, Soundcard, fluidics controller and phaco controller.

A thanks and shoutout to Mike of MikesElectricStuff for tipping me off about this item which was local to me. Thanks Mike!

Teardown: Kodak CR500 Computed Radiography X-Ray Scanner

In this video i begin looking at a Kodak DirectView CR500 Computed Radiography scanner.

A computed radiography system exposes special x-ray plates in regular x-ray equipment but the image is not stored photographically. It's stored in special materials on the imaging plate.

To reveal the image stored on the plate it's digitally recovered using a CR Reader, which is what the Kodak CD500 is. The cassette is offered up the the machine where it extracts the imaging plate from the cassette, scans a red laser over the plate which makes the material fluoresce blue. The blue light is picked up using photomultiplier tubes and then digitised and processed so the image can be viewed on a computer.

The imaging plate is then exposed to bright visible light to erase it for re-use. 

Part 1: Disassembly of the main components.

Part 2: Looking closer at the main components.

Dallas DS12887A NVRAM PC CMOS External Battery Hack

If you have ever dealt with vintage electronics you'll know the feeling when you see a self-contained NVRAM battery module installed into whatever it is. Is the internal battery exhausted? Will the device still operate without it even if it's replaced?

Well this time it was the turn of a Shuttle HOT-433 motherboard dating from around 1997 and it featured a Dallas DS12887A RTC and NVRAM module.  Thankfully being a PC motherboard they are tolerant of a battery failure so i should be able to replace the module and we'll be up and running again.

But then i thought, i know these Dallas RTCs have been hacked open before to gain access to the internal battery so i thought i'd give this one a go and see if i could get the board back up and running without waiting for a new DS12887A to arrive in the post.

So the first procedure was to desolder it and prepare it for surgery, here it is inserted into a IC socket to protect the pins and i have already begun to file down the top of the case to find the battery.

After more filing i eventually revealed one of the battery terminals.

At this stage i also noticed a second terminal just showing through the potting compound circled here in green. Measuring across the large terminal and this small terminal i found 1.2v of a very flat 3v lithium cell.

The next step i broke off the two small welds that attach the large negative battery terminal to break the connection to the internal battery, allowing me to wire in a new connection to an external CR2032 battery clip.

After this was done i installed a socket to the motherboard to allow easy future replacement of the DS12887A RTC.

Once installed the motherboard of course required me to reset the clock and CMOS settings and now the motherboard is working perfectly again.

One that was done and everything proved to be working i applied hot-glue to protect the wires and we're done!

Examining & Repairing A Quantel Paintbox Part 1

The Quantel Paintbox was a set of custom hardware and software that revolutionised the video and TV production industry throughout the world in the 1980s and 1990s. Allowing easy and fast graphics to be produced for broadcast.

Developed by a UK company Quantel the Paintbox went through a number of revisions, the hardware was a custom design based on the Motorola 68000, most of the graphical features were realised in hardware.

I was offered one of the 2nd generation machines dating from 1989 codenamed 'Harriet'. Part of the V-Series of hardware the Harriet was a fully loaded system featuring optional hardware for 3D perspective shaping of graphics and video capture to a large internal RAM store called the Ramstore. Cost at the time of production was around £65,000.

The system is modular, in that there is a backplane which cards are plugged into. Exactly which boards are supplied with the base system and which are optional i am not sure yet. Certainly the main CPU board and video output boards would be standard, in the Harriet there are also the Perspective, Main Store, Main Store 2 and Video Input boards.

The system as i received it included the base unit, keyboard, tablet, pen & cables. Complete with the exception of the 'Rat' which was like a mouse.

My system is currently non-functional, the CPU board is fairly sophisticated however and has some diagnostic features and details the fault as a Bus Error.

The Harriet uses a Motorola 68010 CPU running at 10Mhz, there is a small amount of ROM which stores the bootloader and a CPU monitor, this bootstraps the main operating system from an internal 5.25" SCSI drive.

The Monitor application has a RS232 output port which has a menu and diagnostic features easily accessible with an appropriate terminal application on another computer.

Bus Errors on the 68000 CPU are monitored by external circuitry that asserts the BERR line on the CPU when no data returns on the bus when requested. A simple binary counter is used in the Paintbox clocked from the main oscillator. When the counter reaches a certain point one of the binary outputs asserts the BERR line through an inverter. As memory is accessed and data returned it continually resets the counter, unless there is a fault. When a BERR occurs the CPU jumps to the exception vector for the BERR and executes code there.

In part 2 i will detail more of my investigation...

Sony Betacam Dynamic Tracking Video Heads

During the teardown of a Sony BVW-75 Betacam SP VCR (which dates from 1988) i was delighted to see it used a system called dynamic tracking on the video heads, this is an interesting technology so i am going to take a quick look at how it might be working in this example.

Tracking in video tape machines is an important factor in image quality, in a helical scan tape format the heads must follow precisely the path of the signal else deterioration of the signal will occur.

Methods for controlling this are not simple as timing is critical to get the head which is rotating on the drum to meet the track just at the right time and place.

Dynamic Tracking takes a real time correction approach to this problem. By including additional heads onto the drum which scan and read the the video track just before the actual video heads arrive allows the system to servo the heads to the correct location in real time.

In the picture below you can see the heads on the base of the video drum of this Betacam machine. There are a total of 10 heads.

The two single heads are the rotary erase heads used when recording onto the tape. There are two pairs of fixed read heads on the far left and right of the image and two pairs of read heads that can be moved vertically. The pair of movable video read heads are the larger ones mounted on a separate subframes.

I propose the two pairs of fixed heads are the dynamic tracking read heads, i would expect these to be slightly offset vertically from each other so they should track just above and below the signal on the video tape.

If the tracking is perfect the signal from these heads should be equal, but if there is an offset between them this can be detected and the movable video heads can be adjusted up or down to compensate for the offset in time for the video read heads to scan the tape.

The movable heads are operated by piezoelectric elements driven by i believe a +/- 250v supply generated away from the drum in a separate power supply module.

The video read heads are located on the end of a sandwich of two piezo elements which is the light gold coloured plane in the picture below. This is mounted on a small aluminium frame for support. The connections to the heads run down a flat flex cable just above the piezo element and a number of connections run to the piezo element. The actual video heads can be seen glued to a metallic element which itself is glued to the piezo element.

Close-up Of One Of The Video Heads.

There are a number of connections to the piezo element as i believe this has two elements, one to move the head up and one to move the head down. In the picture below you can see the video heads at the far left, the piezo element is the dark grey area above the aluminium frame and the head signal wires are contained in the flat-flex cable suspended above it.

Top down view of the Dynamic Tracking Video Heads.

Teardown: Sony BVW-75P Betacam SP VCR

In this video i teardown a Sony BVW-75P Betacam SP video recorder & edit deck. The Betacam SP format dates from 1986 but this machine is slightly later and dates from 1988.

The Betacam format, introduced in 1982 is an evolution of the consumer Betamax video tape format that was introduced in 1975 and was aimed squarely at professionals and the broadcast industry.

This BVW-75P is a PAL version Betcam SP edit deck, with playback, record and editing functions.

The Betacam SP format has 340 lines of resolution with 4.5Mhz of Luminance and 1.5Mhz of Chrominance video bandwidth.

The system also uses a mechanism called Dynamic Tracking, which is to allow accurate tracking of the video tape signal using Piezoelectric elements which move the video heads vertically in real time to match the tracking of the video tape it's playing.

Part 1

Part 2


Part 3

Windows 7 WUAUSERV With High CPU & No Windows Updates

I have several PCs in my 'lab', a couple of laptops and two desktops. Of these one laptop and the two desktops run Windows 7 Professional. They are all fully licensed.

My main PC is working fine thankfully but both my laptop (a Sony Vaio from around 2011) and my 'spare' PC are suffering from high CPU load from WUAUSERV. This is actually the Windows Update service which provides automatic updating of security updates.

Thankfully both these machines are not turned on much and i have spent almost zero time to figure out what's wrong with them until now when i have tried to rid myself of these Windows Update issues.

My spare desktop used to be my main PC, it's a little old and decrepit it used to run Windows XP but i upgraded due to the EOL issues with XP. It's Windows 7 Professional 32bit.

As it had been my main PC i thought best thing i can do is just wipe it and re-install windows from scratch.

So this is what i did, the only remaining disk in the system was erased and Windows 7 reinstalled from new from the DVD.

After the usual installation of the odd driver i let windows pull down all the necessary windows updates since the creation of my install disk (Win7 SP1), which it did. Some updates installed and some failed. This is in fact normal in the first run of updates. After each reboot it would pick up a few more as dependences and pre-requisites for the updates change as they are installed.

This is where my issues arrived...

After the last run of updates i found the CPU hovering at 50% usage and the updater seems to be frozen checking for updates. The process is SVCHOST.EXE running WUAUSERV as shown in this screenshot:

I have 172 updates now installed on the system and is probably quite up to date right now (April 2016) but it's stuck now so i wont be seeing any new updates going forward. All i get now is 50% CPU load all the time and the Windows Update dialog shows only the following and never completes an update.

Now this issue is not new, indeed Microsoft have a couple of utilities available to diagnose problems like this. These are the Windows Update Troubleshooter and KB947821 aka System Update Readiness Tool (SUR).

The Windows Update Troubleshooter clears the Windows Update cache, logs etc and also checks a number of things that cause issues with updates.

The System Update Readiness Tool does some magic, to be honest i have no idea what it's doing but i think it goes deeper into checking for problems as it's a 200Mb+ installation compared with Windows Update Troubleshooter which is only a few 100Kb.

Both of these were run with no luck, SUR always exits with no reports so i have no idea what it may have looked for, found or tried to fix. The troubleshooter does have a report at the end which details it's unable to fix error 0x800F081F.

Looking around for this error shows it has a plethora of solutions meaning it's probably some generic failure mode without a specific cause. It is interesting though that this was a clean and freshly installed system. My only conclusion is this is caused by one of the updates arriving by the Windows Update mechanism.

I will continue my quest for a resolution and report back when i have some news.