That query is simply a long running read, without any criteria (so it is running against all data).  As it fetches back the data, it will be done in batches (based on your batch size) and then issue a `getmore` on the same cursor for the next set of results.

The `numYields` count does not mean it is being blocked, it means that it yielded its lock when needed. This is usually done for a write, and usually when it had to page fault to disk to get data, then it resumes.  The query is not being blocked, in fact the `getmore` operations show that it is progressing over time - most long running reads will have a similar profile, especially if you are writing to the database at the same time.

It is also not likely to be the cause of any crash (it's just a read), it's more likely something else that is causing the crash, and you are equating this query with the crash because it happens to be running at the time when the crash occurs (people often suspect the serverStatus command for the same reason - it is run once a minute by MMS).  I would recommend posting the full messaging around the crash as a separate question for proper diagnosis.

For what it's worth, with `snapshot` set to true, and the fact that it is reading all data, I suspect this is a `mongodump` query (it defaults to using snapshot to avoid duplicates being dumped when data is moved).