Can OANOCACHE be used for non-debug purposes?

Friday asks whether OANOCACHE can be used for non-debug purposes, say to improve stability and/or speed.

You can try, but it's not recommended. For one thing, it probably damages stability, because there are many applications out there which unwittingly rely on the BSTR cache to protect them from heap corruption bugs. The Windows team has for years wanted to tweak the BSTR cache (even going so far as getting rid of it entirely), but the compatibility issues always return and quash any attempts at radical restructuring.

Identifying applications that rely on the BSTR cache and deploying an appropriate compatibility shim would be one thing. It's applications which support third party plug-ins that are the sticky point. You say, "Okay, this application is fine, we'll use the new BSTR cache behavior" and then it loads a plug-in DLL that requires the old BSTR cache behavior. Now you're stuck since you don't have a time machine.

Comments (14)
  1. Joshua says:

    Once again, I see a very good reason to want to ban all shell extensions, etc. from loading into my app. It is unfair to have to debug crashes or weird behavior caused by plugins when I don't even load plugins myself.

  2. Kyle says:

    If the shell was designed today, would Microsoft have disallowed in-process shell extensions, only allowing out-of-process extensions?  At least that way it would be harder for extensions to cause issues in the shell process.  I'm sure fewer available computing resources at least partially drove the decision originally, but would a different choice be made now?

  3. DWalker says:

    Re the discussion about debug and checked builds at the other link:  The term "checked build" is weird; it sounds like the build was checked out, whereas the non-checked build was just thrown together and not "checked"!  It's too late, but maybe the "checked build" should have been called an "assertion build".

  4. Gabe says:

    Joshua: What would your users say when the Open/Save dialogs no longer work as they expect them to? I can think of few apps where I wouldn't want care if shell extensions didn't work.

    Kyle: If the shell was designed today, they might not realize that bad shell extensions would cause so many crashes, so they might not consider that it would be necessary. On the other hand, maybe they would have learned from IE plug-ins and put them in a different process.

    BTW, why did they cache BSTRs to begin with? Since they're not all the same size, it seems like it wouldn't be a big win. I suppose the memory allocator overhead was more of an issue back when BSTRs were created.

  5. Friday says:

    I used it ever since then (in fact I even forgot I had put it there) and I never saw any apparent problems. Light home usage, browsing, office apps, image processing…

    Maybe the hardware has grown so fast it can't be noticed?

    And I tried it in the first place because I don't want any leaks (as per Larry's article). Maybe I got it all wrong, as I said, I'm not a programmer.

  6. AC says:

    What would your users say when the Open/Save dialogs no longer work as they expect them to?

    I've had to debug a really weird bug in our app where it would behave strangely after a while, but it was only reproducible on some machines. Turned out to be after calling the open / save dialogs which injected a shell plugin into the process. The shell plugin went ahead and changed the locale, creating parsing problems.

    Duh, that was a pain to find out. I'd probably still be debugging this if Raymond's psychic powers hadn't told him to queue an article about exactly this a little over 2 years ago.

  7. Joshua says:

    @Gabe: Let's just say I publish my app with an on/off switch for shell extensions. If someone's getting a weird crash and I'm getting nowhere, I tell them to try to reproduce with the switch thrown.

  8. Anonymous Coward says:

    Jushua, I see where you're coming from, but in practice all applications would ship with the switch turned off, leaving the average user with dialogues that don't work as expected.

    The only effective way to debug crashes (at least in experience) is to look at the address/line where the crash happens and check what's in the registers anyway, so in practice the off switch might not even be that big of a benefit.

    It also harks back to countless talks with Q&A people asking be to toggle all kind of pointless unrelated settings and to come back when the crash happens again. I think it's just a way to postpone having to deal with the problem until next week, and it also shows why the reproduction first mentality of crash debugging doesn't work for the majority of crashes, since they often happen sporadically and unpredictably.

  9. TC says:

    All crashes can be reproduced repdictably. Just demonstrate the allegedly finished product, to senior management!

  10. Gabe says:

    TC: I'm afraid that the only way to get a trouble-free demo for upper management is by attempting to reproduce a crash!

  11. voo says:

    @Gabe: I think we're on to something. Finally a way to beat murphy!

  12. Joshua says:

    @Anonymous Coward: More than half of the reported crashes to me, when the problem is found, turn out to be caused by third party code that does not exist in dev or test.

    After directly fingering a specific version of TrendMicro (perfectly reproducible crash only while that version of TrendMicro was installed), I started getting a bit touchy about it.

  13. Joshua: I've sometimes found irritations like that – of course, if the problem showed up in the dev environment, the code would never have gone out like that in the first place! I had a very frustrating time once, getting a BugCheck when I called NtClose. Needless to say, an AV app (not the one you mention) had hooked NtCreateFile and NtClose; their close hook seemed to be relying on some internal state being set up by their open hook, which wasn't happening in the particular way I was using it. Very irritating!

  14. cheong00 says:

    I had bitten by 3rd party bug as well. That is related to a form that used embedded web browser control, but the user's running a PC that have IE bugged to a level that it can't be started. (This user normally used Firefox so thought it wan't a big deal, and didn't report the issue to I.T. staffs.)

    A fresh reinstallation of Windows cured that.

Comments are closed.

Skip to main content