Job 'pending' for 13hrs

[Wintel]

Veeam 6.0 patch 3 installed on 64bit W2K8 backing up Windows VMs on vSphere ESXi 4.1 update 2.

One of my file server jobs has started to hang - realtime statistics show 0KB/s for all, and the first VM in the list has status 'pending' with nothing listed in the right-hand action/duration pane. This VM is not even switched on. It's been like this for over 13hr now.

I've tried to stop the job but no immediate luck. I've quit and restarted the Veeam console but it still shows 0%.

What's the best way to kill this job, and if it goes pending when I restart, how do I troubleshoot it?

[Wintel]

Update - the job (only 2 VMs, first one is not even switched on) has now failed.

Job details:
18/06/2012 20:00:30 :: Job started at 18/06/2012 20:00:03
18/06/2012 20:00:30 :: Building VM list
18/06/2012 20:01:32 :: VM size: 2.4 TB (2.4 TB used)
18/06/2012 20:01:32 :: Changed block tracking is enabled
19/06/2012 11:51:35 :: Removing 'J:\Veeam-J\svr04\svr042012-06-02T200124.vrb' per retention policy
19/06/2012 11:51:39 :: Job has been terminated
19/06/2012 11:51:39 :: Job finished with error at 19/06/2012 11:51:39

The VM details:
19/06/2012 11:50:50 :: Queued for processing at 19/06/2012 11:50:50
19/06/2012 11:50:50 :: Required resources have been assigned
19/06/2012 11:51:39 :: Job has failed. See logs for details.
19/06/2012 11:51:39 :: Processing finished with errors at 19/06/2012 11:51:39

19/06/2012 11:50:50 :: Queued for processing at 19/06/2012 11:50:50
19/06/2012 11:51:39 :: Job has failed. See logs for details.
19/06/2012 11:51:39 :: Processing finished with errors at 19/06/2012 11:51:39

where do I find the logs it talks about?

[foggy]

Product debug logs are located in the %programdata%/Veeam/Backup folder. Your best bet would be to open a support case and provide the logs for investigation to our technical specialists.

[Wintel]

thanks foggy. I've actually removed the switched-off VM from the job and rerun, and the live server is now backing up ok. I'll raise a call anyway and pass the logs for diagnosis to see if there are any underlying problems that might cause this to happen again.