Limitations of the FindStr Utility

Readers have noted that I use the FindStr utility quite often. This utility is documented in both Windows Command-Line Administration Instant Reference and Administering Windows Server 2008 Server Core (and also appears a host of my other books). At the time I wrote that documentation, I had no idea of how much comment this particular utility would generate. I’ve written a number of posts about it, including Accessing Sample Database Data (Part 3), Understanding Line-, Token-, and String-Based Command Line UtilitiesUsing the FindStr Utility to Locate Errors in Visual Studio, and Regular Expressions with FindStr. It might be possible that people think that this utility is infallible, but it most certainly has limits. Of course, the FindStr utility is line-based and I’ve already documented that limitation. However, it has other limitations as well.

The most important limitation you must consider is how FindStr works. This utility works with raw files. So, you can use it to look inside executable files and locate those produced by a specific organization as long as the file contains unencrypted data. When an executable relies on obfuscation or other techniques to render the content less viewable by competitors, the strings that you normally locate using FindStr might become mangled as well—making them invisible to the utility. In practice, this particular problem rarely happens, but you need to be aware that it does happen and very likely will happen when the executable file’s creator has something to hide (think virus).

Another problem is that FindStr can’t look inside archives or other processed data. For example, you can’t look inside a .ZIP file and hope to locate that missing file. You might initially think that there is a way around this problem by using the functionality provided in Windows 7 and newer versions of Windows to look inside archive files and treat them as folders. However, this functionality only exists within Windows Explorer. You can’t open a command prompt inside an archive file and use FindStr with it.

Recently, a reader had written me about his Office installation. Previously, he had used FindStr to locate specific files based on their content—sometimes using content that wasn’t searchable in other ways. This feature suddenly stopped working and the reader wondered why. It turns out that .DOC files are raw, while .DOCX files are archives. Change the extension of a .DOCX file to .ZIP and you’ll suddenly find that your ZIP file utilities work great with it. Old Office files work well with FindStr—new files only work if you save them in .DOC format.

Another reader wrote to ask about network drives. It seems that the reader was having a problem locating files on a network drive unless the drive was mapped. This actually isn’t a limitation, but you do have to think about what you want to do. Let’s say you’re looking for a series of .DOC files on the C drive (with a shared name of Drive C) of a server named WinServer in the WinWord folder that contain the word Java in them. The command would look like this: FindStr /m /s “Java” “\\WinServer\Drive C\WinWord\*.doc”. When using network drives, you must include the server name, the share name, the path, and the file specification as part of the command. Otherwise, FindStr won’t work. What I have found though is that FindStr works best with Windows servers. If you try to use it with another server type, you might experience problems because FindStr won’t know how to navigate the directory structure.

There is a real limit on the length of your search string. Another reader wrote with this immense search string and wondered why FindStr was complaining about it. The utility appears to have a search string length limit of 127 characters (found through experimentation and not documented—your experience may differ). The workaround is to find a shorter search string or to perform multiple searches (refining the search by creating a more detailed file specification). If you can’t use either workaround, then you need to write an application using something like VBScript to perform the task.

These are the questions that readers have asked most about. Of course, I want to hear your question about limitations as well. If you encounter some strange FindStr behavior that affects my book’s content in some way, please be sure to write at


VBA and Office 2013 (Part 2)

I had posted some comments about using VBA with Office 2013 in my VBA and Office 2013 post. This post was based on the preview and not on the released product. Even so, most of the comments in that post still hold true. If you’re working with the desktop version of the product, you’ll find that most of the examples in VBA for Dummies will still work fine. However, the book is getting long in the tooth and the last version of Office that worked absolutely perfectly with the book was Office 2003. Since that release, Microsoft has made it progressively harder to use VBA as a viable development solution for the power user, hobbyist, and even the less skilled developer.

There are some new issues for Office 2013 that you need to know about. Most notably, it appears that some people can’t even access the Templates folder any longer without resorting to a kludge. By default, Office 2013 displays the templates and hides your personal templates, which should be a real productivity killer for the enterprise environment where custom templates reign. Yes, there is a fix for the problem (just click the links I’ve provided), but the issue is that you have to apply the fix to individual systems.

The fact of the matter is that Microsoft is making it abundantly clear that it would prefer that you not write applications for Office unless you’re willing to use Apps for Office. However, the process for creating an application in this manner is hardly as straightforward or as easy as using VBA. As far as I know, the template issue only affects one of the examples in Chapter 11. Please let me know if other chapters are affected by this issue (or any other Office 2013 issue for that matter). You can use the example in Chapter 11 after you apply the fix that is provided by Microsoft or third parties for regaining access to your personal templates.

Microsoft is also making a strong push for Office 365. This online version of Office can’t use VBA in any form. Even if you have your own templates and have carefully crafted VBA macros that would run with the desktop version of the product, you’re out of luck when it comes to Office 365. If you have this version of Office, you simply can’t use my book—attempting to do so is a waste of time.

You can continue to get full support for VBA for Dummies with desktop versions of Office, but may have to resort to some special changes as Microsoft makes Office less amenable to use with VBA. Please make sure you read the VBA for Dummies posts on my blog for updates and help with both Office 2007 and Office 2010 before contacting me.

Anyone who is attempting to write VBA macros for Office 2013 is in for a rough time and I’m sorry to see an era of personal productivity through VBA enhancement passing. If you own Office 2013 and contact me regarding VBA for Dummies, I’ll provide the best help that I can to you, but this support will be necessarily limited. Thank you for your continued support of my books. Perhaps I’ll eventually write an Apps for Office book to supplant VBA for Dummies. Please contact me with any concerns you have at


VBA and Office 2013

First, the good news about Office 2013. Despite Microsoft’s best efforts to kill VBA off, it still hasn’t managed to do so. In running the various examples supplied with VBA for Dummies, I find that they all apparently run the same as they do for Office 2010. Consequently, you should still be able to follow the examples in my book without too much trouble. The Ribbon definitely will cause the same amount of trouble as it always has and you should read the posts in the VBA for Dummies category of this blog when working through the book. Remember that these assumptions are based on the current Office 2013 Customer Preview and not on a released product. I also tested the examples on Windows 7, rather than Windows 8. If anyone encounters issues working through the VBA for Dummies examples, I’d very much like to hear about them at

Second, the bad news (isn’t there always some bad news). I’ve been reading about some of the experiences other people have had with Office 2013. In fact, I’ve been trying to test some of these concerns as I work with Office 2013 because I’m almost certain that some of you will write me about them. Most of the issues seem to run on the esoteric side. For example, a number of people are reporting that Office 2013 has problems with animations that are supplied as part of a VBA macro. The issue seems to be one of timing, which is probably one of the more difficult aspects of a VBA macro to troubleshoot. My advice with these sorts of issues is to focus on the macro output for right now. When the inputs and outputs work as expected, the user is generally happy. Yes, features such as animations add pizzazz, but they don’t necessarily help users perform useful work. Even so, Microsoft will probably fix a few of these issues before product release. To obtain the best help with your particular question, check out the Microsoft Office forum.

Third, the surprise news is that Microsoft is even mentioning VBA in some of the Office 2013 documentation for developers. You can find an overview of developer information at What’s new for Office 2013 developers. Many of the changes you’ll find are quite technical (such as working with the new DataModel object model). I was also quite happy to see that there is a new user interface (a task pane) for creating the XML mappings required for content controls, so you don’t have to resort to using any of those weird file manipulation methods of the past. Once Office 2013 is released, I’ll cover a few of these topics in my blog. Make sure you check out the pages for the individual applications as well:

It’ll be interesting to see how users react to the modified Office interface. My thought is that Microsoft is trying to reduce the power consumption of its applications by reducing the complexity of the user interface. However, no one at Microsoft is really saying much except that the older Aero interface looks dated and cheesy.

You’ll also want to remember that Microsoft is maintaining VBA, not really enriching it in any significant way. If Microsoft had its way, VBA would disappear with the flash of a magician’s hand. Unfortunately for Microsoft, far too many people still use VBA to create productive applications. The Visual Studio Tools for Office (VSTO) add-on has attracted a lot of attention from professional developers, but it’s far too complex for the typical office manager to use. The new focus is on something called Apps for Office. The overview for this new technology doesn’t fill me with a lot of hope that it’ll replace VBA anytime soon, but I’d love to hear your opinion about it.

For better or for worse, you’ll soon be finding yourself supporting another version of Office. In this case, you’ll likely find that VBA takes a few more hits in the compatibility zone. Microsoft is pushing hard to get developers to use anything other than VBA and developers seem equally convinced that VBA is still the right choice. I support using the right tool for the job. As long as VBA provides a simple environment for creating macros that perform useful work with a minimum of headaches, I’ll continue supporting it. In that regard, count on my continued support for VBA in Office 2013.