This may depend on your mapping. If it is a typical text field type as opposed to a keyword field then the string value will have been tokenized by an analyzer and effectively been indexed as multiple token strings e.g. hkcr, mscfile, shell, open, command and default.
Your first query which is looking for *mscfile* will match the mscfile token.
However, the second query which looks for *mscfile*shell* will not match tokens mscfile or shell.
This is the problem with "opinionated" indexing that slices strings up on boundaries (typically whitespaces and punctuation) and is more suited for dealing with matching words in free-text content like the words in this paragraph.
For exact-sequence matching problems like yours, you don't care about slicing content into tokens and while you can use leading wildcard queries on untokenized keyword fields it is not terribly efficient (cost is linear with number of unique strings). This is why we are working on a new field type that is optimised for this sort of matching.
This is not available yet so you will have to either:
- Suffer slow speeds using leading wildcard queries on a
keywordfield type or - Write more complex queries (see "interval" queries) that deal with the fact that the orginal content is tokenized into multiple words.