Suspect (Torn) Pages regarding tempdb? I have a virtualised SQL Server 2005 (SP3) that reported the following message:

Database_Name, Database_Id, File_Id, Event_Type, Event_Type_Desc, Error_Count, Last_Update_Date
tempdb, 2, 1, 3, Torn page., 1, 10 Dec 2014 06:32:36:033
tempdb, 2, 1, 3, Torn page., 1, 10 Dec 2014 06:32:36:043
tempdb, 2, 1, 3, Torn page., 1, 10 Dec 2014 06:32:36:050
tempdb, 2, 1, 3, Torn page., 1, 10 Dec 2014 06:32:36:057
...


It is the second time in the past month that I've seen this error on this particular server - and in both cases it was in tempdb, with Event_type = 3 (i.e. Torn Page) only. It has never been Event_type = 1, which corresponds to an 823 (disk error) or 824 error.

Running the command:

DBCC CHECKDB WITH ALL_ERRORMSGS, PHYSICAL_ONLY


returns:

DBCC results for 'tempdb'.
DBCC CHECKDB will not check SQL Server catalog or Service Broker consistency because a database snapshot could not be created or because WITH TABLOCK was specified.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'tempdb'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.


In other words, everything seems fine, but why then is suspect pages getting recorded?

Other actions taken:


HDDScan / chkdsk run to make sure its not a drive error (there is also nothing relevant recorded in the windows event logs around the time of the error).
PAGE_VERIFY is currently set to NONE (default?) - investigated the possibility of setting it to CHECKSUM, but that's only possible for tempdb in SQL Server 2008 onwards.
Stopped SQL server, deleted existing tempdb files, restarted it (based upon a comment in 
the question -> How might a corrupt partition in TempDB result in DBCC CHECKDB reporting no error
Read the similar questions (to the right) but none of them are relevant.


Is there anything else I should be checking / doing, or should I simply disregard this because its TempDB (i.e. transient data)?

Thanks for any assistance/input.
You need to work with your storage vendor to figure out why the writes are being torn. If it's happening to tempdb it's very likely that it's happening to another database as well. 

This is especially true if it's happened more than once.