Nuke will happily render to thin air without an error, going through all the motions and then writing the frame to the bit bucket. This often happens when the destination folder for the rendered frame is either not accessible, prohibits writing due to permissions, or is full.
Permissions can be hard to track down; some workers may be running under a different proxy_account than others, so you may want to check and see if the failed frames are all from the same worker or workers, and if those workers are able to write earlier or later frames.
If a worker can write frames for a while, then fail to write, then be able to write again all within the same job, the usual cause for that is the file server is running a Windows desktop O/S version, which only supports a limited number of concurrent connections and will silently drop a connection to pick up another one. The client on the other end has no clue that the network connection to the filesystem is dead. The clue to this is when the number of dropped frames goes up as the number of running instances for all jobs on the farm goes up.
