Same command inconsistent results:
Don't ask why I use two dd commands in a pipe, it's from a longer pipe, simplified.

root@Dell /ADSG2/3LOADER/decompress # cat linux.tar.lzo | dd bs=1M count=10 | dd of=part1
9+1 records in
9+1 records out
10452992 bytes (10 MB) copied, 0.123541 s, 84.6 MB/s
20416+0 records in
20416+0 records out
10452992 bytes (10 MB) copied, 0.119962 s, 87.1 MB/s
root@Dell /ADSG2/3LOADER/decompress # cat linux.tar.lzo | dd bs=1M count=10 | dd of=part1
8+2 records in
8+2 records out
8585216 bytes (8.6 MB) copied, 0.100906 s, 85.1 MB/s
16768+0 records in
16768+0 records out
8585216 bytes (8.6 MB) copied, 0.0932617 s, 92.1 MB/s
root@Dell /ADSG2/3LOADER/decompress # cat linux.tar.lzo | dd bs=1M count=10 | dd of=part1
9+1 records in
9+1 records out
10059776 bytes (10 MB) copied, 0.110897 s, 90.7 MB/s
19648+0 records in
19648+0 records out
10059776 bytes (10 MB) copied, 0.104878 s, 95.9 MB/s
root@Dell /ADSG2/3LOADER/decompress # cat linux.tar.lzo | dd bs=1M count=10 | dd of=part1
2+8 records in
2+8 records out
2883584 bytes (2.9 MB) copied, 0.0362805 s, 79.5 MB/s
5632+0 records in
5632+0 records out
2883584 bytes (2.9 MB) copied, 0.0312908 s, 92.2 MB/s
root@Dell /ADSG2/3LOADER/decompress # cat linux.tar.lzo | dd bs=1M count=10 | dd of=part1
9+1 records in
9+1 records out
10452992 bytes (10 MB) copied, 0.117168 s, 89.2 MB/s
20416+0 records in
20416+0 records out
10452992 bytes (10 MB) copied, 0.113231 s, 92.3 MB/s
root@Dell /ADSG2/3LOADER/decompress # cat linux.tar.lzo | dd bs=1M count=10 | dd of=part1
2+8 records in
2+8 records out
2883584 bytes (2.9 MB) copied, 0.0359303 s, 80.3 MB/s
5632+0 records in
5632+0 records out
2883584 bytes (2.9 MB) copied, 0.0285703 s, 101 MB/s

The suspect bit to me is the middle |dd <blah> | bit.

You're using stdin & stdout and there might need to be a dash for those (if=- of=-) Check man page

You can also simplify the above chain of | dd bs=1M count=10 | dd of=part1 to
|dd if=- bs-1M count=10 of=part1
further, to specify bs and count, you have to know the exact file size. You can stabilise even further and prevent rounding errors by leaving them out
|dd if=- of=part1

So actually, the entire middle portion of your command seems unnecessary and is error prone. Try
cat linux.tar.lzo | dd of=part1

cat linux.tar.lzo | dd if=- of=- bs=1M count=10 | dd if=- of=part1
dd: opening `-': No such file or directory
dd: opening `-': No such file or directory
from the manual: dd uses stdin and stdout by default, no need to use dashes.

About simplifying, as I said this is from a longer pipe, something like:

curl http://x.x.x.x/file | dd bs=1M count=10 | openssl des3 -d -k "password" | dd of=part1

*the idea is to decrypt only the first 10MB of a larger file.

Maybe It faces read errors and ends early. Why it would face a read error is something I don't know.

I would have liked to have had the actual command that wasn't behaving itself.

I still stand by my comment that bs and count are unwise options to pass to dd together as they imply you know the exact file size.

The commands are:
cat linux.tar.lzo | dd bs=1M count=10 | dd of=part1
or
dd if=linux.tar.lzo | dd bs=1M count=10 | dd of=part1
The funny part is that sometimes it works ok, so I started messing with bs and count (bs=1M/count=10, bs=100k/count=100, bs=1k/count=10240, bs=512/count=20480) as bs is smaller the chance of working is higher, so my conclusion is: if the buffer from the previous command is not filled enough the command reads EOF and closes, should wait but it does not.