Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 

Sign in to follow this  

Obnoxious find bug, related to NFR 1.1

Recommended Posts

Scenario: In a machine set-up with Win 98SE and IE6, either fully updated or just plain vanilla, having more than one fixed drive (more than one partition is enough), select "Start -> Find -> Files or Folders" and "Local hard drives" or "My Computer", and give "*.vxd" as search mask: the search will proceed from C: to the last fixed drive letter, as expected. Do the same, but using one of the following masks: "*.c*", "*.d*", "*.dll", "*.e*", "*.exe", "*.f*", "*.i*", "*.j*", "*.m*", "*.o*", "*.r*", "*.reg", "*.s*", "*.t*", "*.tlb", "*.v*", "*.w*", "*.x*" or "*.xml": now the result can be a search through all the fixed drives or <the BUG!> if MS .NET Framework Redistributable 1.1 is installed, the search will proceed to the end of drive C: and then stop.

Workaround: search each drive letter individually, and all goes well.

Solution: I've not found any, up to now.

By removing .NET 1.1, the bug goes away. On reinstalling it, it reapears, so there can be no doubt it is due to .NET 1.1... It is so strange, on the other hand, that it seems to be "by design", but I don't see the point of it.

Have any of you found this condition before? Do you know any solutions that preserve the .NET installation? Is it due to any configurable policy or the like? Your advice is most welcome.

Adding .NET 2.0 to a system that already has .NET 1.1 does not affect the bug. Removing both .NET 1.1 and 2.0 remove the bug yet again... But (new info) removing .NET 1.1 and installing .NET 2.0 alone also results in the same bug. So standalone .NET 2.0 also causes the bug. As before, removing standalone .NET 2.0 removes the bug.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.