First, an answer to the original asker's (now ancient) question.
Unlike some tools (like ophcrack), NTLM hashes need to be separated out into their LM and NTLM components for hashcat to attack them separately,
either hashes only:
$ cat lm.hashes
[lm-hash1]
[lm-hash2]
$ cat ntlm.hashes
[ntlm-hash1]
[ntlm-hash2]
... or with users (which requires using the --username hashcat parameter):
$ cat lm-users.hashes
user1:[lm-hash1]
user2:[lm-hash2]
$ cat ntlm-users.hashes
user1:[ntlm-hash1]
user2:[ntlm-hash2]
This post from Didier Stevens outlines how to use the LM cracks (case-insensitive) to then attack the case-sensitive NTLM hashes.
Second, since the number of views that this question has (3K at this writing!) is a testament to how often this error confuses people, here's a more general answer.
hashcat throws the dreaded "line-length exception" error when hashcat receives something that it tried to interpret as a hash, but the data received is not the expected length for the requested hash type.
I phrase it in this specific way because it's important to understand that some natural activities might cause this in surprising ways. When you're working with hashcat command line, it's easy to accidentally pass it something that hashcat is expecting to be a hash, but isn't -- so much so that there is a hashcat FAQ entry for the error.
The common triggers include:
The hashes aren't the type that you think they are, so the hash length doesn't match the requested type. This is often the most common, and the first thing to check. The best way to verify is to try the same command against the corresponding example hash in the hashcat example hashes list.
The hashes have unexpected characters at the end (often whitespace).
The supplied hashes include users or salts when they aren't expected (or they don't contain those, and they are expected). For example, you might supply hashes in a "username:hash" or similar format, but hashcat can't tell if "string:string" is really "hash:salt" or something else instead (use --username if you need to work on "username:hash" hashes).
Because of a typo or mis-ordering of command-line options, you accidentally pass a non-hashes file as the first "unflagged" parameter to hashcat. This is also quite common. For example, if you accidentally forget to put -r in front of a rules file, and you haven't specified a hash file yet, hashcat will think that that first "unflagged" parameter is your target hashfile, and will try to "crack" it. (Corollary: it's a good idea to place your hashfile relatively early in your command line, before anything else that takes a file as a parameter, to reduce the chances of this)
(I saved the weirdest one for last): When you are passing a file containing a list of hashes on the command line, but the file doesn't exist. This is because of a quirk in how hashcat processes the command line. The syntax for "hashcat [literal-hash-to-crack]" and "hashcat [file-containing-hashes-to-crack"] is exactly the same. This means that if you pass a file but it doesn't exist, hashcat says to itself "hmm, that thing they asked to crack wasn't a file, maybe they're trying to specify a hash directly?". Since the filename is almost never the same length as the hashes of the target hash type, you'll get the "this is the wrong length" error when what it really means is "the file doesn't exist".
So as long as you interpret the error as "there is something wrong with my input", and you investigate each of these possibilities, you should be able to resolve any "line-length exception" errors.
I'm very new to cracking a password so sorry if I sound stupid.
