Most computers only understand how to render 3 to 4 band images, where each band is in bytes. This means that each pixel you view on your computer will have 3 to 4 bytes of data, representing each of the bands. The fourth band is the transparency band, with values indicating how transparent the pixel is. The rest of the bands represent Red, Green, Blue (RGB), giving you a color space of 0 to 255 (integers only) for each band allowing you to view up to ~17 million different colors for any given pixel.
The problem is, when we provide a true Digital Surface Map (DSM), or some of our other products, it either a) not have 3 bands or b) the bands are not represented by bytes. In the case of the DSM it will have both issues. So our DSM have one or two bands; the second being, again, for the transparency if it exists. This band is represented by a 32-bit float value, and it allows us to represent values like 5892.1 which could be a true elevation, versus the 8-bit (8-bits = 1 byte) integer value of the RGB colorspace. The problem now is that your computer will have no way to know how to represent a value of 1.123 and 53482.123 in the same image without guessing (plus there would be significant processing/memory costs), and so it doesn't, thus you get blank images. This is why we use GIS software to render these images since it has the tools to interpret these values and it has a default "best guess" view when you load it in. Example being QGIS: It usually defaults to a grey scale image that has black represent anything below 2% and white represent anything over 98% of the cumulative sum of pixels.
In the end, just follow these notes: If an image is blank, try loading it into QGIS or some other specialized GIS software before contacting support about a blank image. These images are usually specialized output formats for doing data manipulation. However, we are constantly making improvements to our data, so it may actually be we provided you a blank image, but it helps us if you verify first.