The issue was the loaded firmware. After re-burning the firmware onto all the chips, everything appears to work.

Funny that all the chips I ordered had the same corrupt bootloader.

Synopsis

AvrDude is just passing through an error reported by the AVRISP, which means it can't communicate with the target.

Request for more detail

I'm assuming you are using an STK500, but we'll need a bit more detail for a more precise answer. You could start by telling us which MCU you are using as the target. If you post a netlist of your programming port connections or (better) a schematic, I can assist you further.

Generic causes

That said, the red light can be caused by any of the following generic things:

1. No power at the target -- you ruled this out with your dmm.

2. Incorrect pin-mapping -- the AVRISP Mark 2, uses a different pin-out for different targets. You have to make sure you wire it correctly for your host. You could also have made a mistake in the pin numbering of your PCB footprint (if you made a PCB) or jumper wiring (if you are using a breadboard). You should check (in this order):

   1. The reset pin (measure on the MCU) idles high, then goes low when you initiate AvrDude operations, and returns high once the error is reported to the console.

   2. That the programming clock from the AVRISP arrives on the correct pin of the target MCU.

   3. That the data clock from the AVRISP arrive on the correct pin of the target MCU.

3. Incorrect target MCU specified -- the AVRISP Mark 2, uses its pins for different functions depending on which MCU it is targeting. If you tell it the wrong target, it may look at the wrong pins for the signal, not find the line in a driveable or idle condition and report an error.

4. In older targets (like the ATMEGA103/128 family) the clock speed matters. You can't clock the AVRISP data stream faster than 1/4 the clock speed of the target.

Diagnostic aide

The very first thing you should do is switch to the latest AVR-Studio, update the firmware in the AVRISP, and try to use the included programmer software (Atmel's version of AvrDude) to do something as simple as read the chip's device ID. This will confirm that all of your hardware is ok and isolate the problem to that of a misconfigured AvrDude.