Hashcat exhausted, yet password is in dictionary
(Testing my own router, that's how I know password is in the dictionary ...)

I'm using airodump-ng to get the capfiles and using aircrack (or hashcat's online tool) to convert to hccap.

Pyrit, cowpatty, and others all tell me the .cap is fine. Yet, it really isn't... 

Can someone tell me exactly how to check the .cap for what the problem might be?
Typical WPA case and it's always because of a bad handshake capture. Just do a new one.
Thank you - and that is true, a new cap worked fine.

But what I mean is - in a situation like that, I never know if Hashcat is exhausted because the word isn't in the list.. or because it's a bad cap..

Only way I discovered this was because it was my own router.

Is there something in Wireshark I can look at, to see why the first cap failed? (and why aircrack and pyrit said it was a good cap, when it wasn't)?
There are several cases. Packets are far apart in time (say over a second, while ideally should be slightly more then 0.05 seconds). Packets are near in time, but from different sessions. Roughly (without technical details) the router sends, for instanse, 50 requests with some mark (session's mark) and waits for a response. Next 50 requests it sends with other mark (other session). It was captured a request from one session (say number 50), and the response from the other (say number 1). The right responses were missed. Due to the session's marks do not match test with correct password will not be successful. Sometimes the packages may be slightly damaged, but programs don't see it. Need to open capfile by wireshark and choose good/another pair of packets, delete all others, save as another capfile and try it.
Thanks PutNick that makes some sense to me..

If I load up the cap in Wireshark what would I look at to see if this is the case
Avoid packets marked light blue or light red, choose packets with small time interval. You need pair of key 1-2 or 2-3 (key 1 of 4 and 2 of 4 or 2-3 resp.) and any beacon frame (time distance from key pair doesn't matter). Probe response or assotiation request also good instead of beacon frame (time distance doesn't matter also).
Latest hashcat beta adds some help for that, new feature. You can add as many handshakes as you want (to make sure there's at least one valid) while cracking them all at once takes the same time as a single handshake.

So for all you WPA crackers out there, add as many handshakes of the same ESSID as you can to your hccap.