Perflib bug!

  • Thread starter Thread starter Guest
  • Start date Start date
To delete it post FBA, you may need to boot to an offline OS, like WinPE
or something else, then load the hive offline to edit it. Please let us
know if this helps or not.
 
Hi Andy,

Thanks but this does not help since we need to supply a patch to fix this
issue for products that has already been shipped to customers.
Is there ANY way to delete this key programmatically? Which application is
using this key and therefore preventing it to be deleted while the system is
running?
 
Per,

Unless the key is locked by another component (maybe the case if performance counters are on) you can log in as Local System account
and run regedit there either in automatic mode or manually with GUI to delete the key (use "at /interactive" command).
 
Yes, this key is definetly locked by another system component. So, it does
not matter which user that is trying to delete this key. Anyone who has an
idea how to get a list of registry handles used by a process? :-\

Would it work to load a driver just after the software hive has been loaded
and then delete this key? Is there anyone that has other ideas before I spend
more valuable time on this?

Thanks
 
Use ProcessExplorer tool from www.sysinternals.com.
It will show you all the objects used by a process including reg.keys.


Simple idea for you (I've done that long time ago so it definitely works).
You can still delete the key offline, meaning from another OS load.
Since the system is already deployed to the field you can automate the process:
(below I'll refer to the image you already have on the devices as "big image").
- Create a really small XPe image that would be able to use reg.exe (or regedit.exe) from CMD.
Set the image up so that it uses something like \Windows2 dir for the system folder (so that it doesn't interfere with
your main big image if laid out on the same drive).
- Set up the shell of the small XPe image so that it runs a few commands to load the big image's system reg hive and delete
the specified key (reg.exe supports all the commands you need).
- Deploy this image to the field via your current update transport (DUA? something else?).
- Update boot.ini on the disk (just replace it with a new downloaded boot.ini) so that it defaults to load that small XPe
image.
- Reboot the device.
- Small XPe image should be launched here and run in automated mode (e.g., CMD shell may call to a batch file) the
predefined set of commands to update the big image's hives. Then it should update boot.ini to use the big image's \WINDOWS in a
default ArcPath, and finally reboot.

Theoretically you don't even have to clean up the system and delete the small image afterwards. But if you want to it is also easy
to automate. You just have to add a self-deleting batch file call to the StartUp items of the big image. The batch file should
remove all the temporary files and folders.

License-wise you can use the same PID for the small XPe image because:
- the image is only used in the update, system recovery or repair process.
- the image existence is only temporary during the update.

Does this make sense?
 
That makes sense but it just seems like too much hassle to build a new
"small" system to have this key deleted.
We have three different hardware configurations in the field and it really
would save time to only have to create one update to solve this issue.

Do you have any idea who big this "small" system would have to be? I guess
it would end up around 30-40MB?

Thanks
 
Well, it depends on what else you want to accomplish from within that small image.

If I followed your requirements properly, a Minlogon+CMD+reg.exe image would do that.
This means you are potentially looking for a 15-20 Mg image.
Compressed (e.g., zipped) if would probably go to 5Mg (up to 10).


Another couple ideas for you:
- Just stopping "Remote Registry" service at run time and then try to delete the Perflib key.
- If the above doesn't help, you can temporarily disable performance counters for all services on your image, reboot (or
just restart the "Remote Registry" service) and then it may release the Perflib key so that you can delete it.
 
An image with Minlogon+CMD+reg.exe built for Virtual PC is 37,5MB
uncompressed and 19MB compressed. Any ideas on how to build a smaller image?
I keep hearing that the smallest footprint is 5MB, but how can you actually
build that "small" image? Why is there not an MSDN article available that
explains how to build a 5MB XP Embedded image? (if it is possible!)

Anyway, the solution to delete the key from a "small" image by loading the
registry key offlince does not work. When trying to delete the \Perflib\009
key from the "small" image the result is: "the key cannot be found". After
checking with Process Explorer to see which process is dynamically loading
this key it turns out to be a process named "smss.exe".
(Windows NT Session Manager)

So, it seems to be impossible to correct this issue on already deployed
systems(?)

Thanks.
 
First of all, to prove the concept please load the main [big] image's software hive offline (use XP Pro machine, regedit) and check
if the key is there.
I started to think you are right. The PerfLib key must be there even offline but the 009 subkey gets created by performance counters
at run time and therefore you will unlikely be able to see it in the offline hive.
I think the original bug was that Microsoft componentized the Performance Counter Configuration with the 009 key accidentally added.
For proper performance counter configuration you wouldn't want the key pre-created.



Just for the record about footprint reductions... (might not be relevant to your issue now)
Well, 5 Mb is kernel only image (even bigger on SP2). You will have to program your app(s) using kernel APIs. Possible but hell lot
of work.

I am surprised your image is that big. Did you happen to use a template, e.g. Minlogon Macro?
Then please remove all the network related stuff. Obviously, for the purpose of that small image you won't need that.

Also, did you include your hardware related stuff (e.g., the platform macro you got from importing TAP result)? Then it would bring
over too much stuff you might not need.

Check and delete everything you don't need in that image. From Audio support to video drivers (you only need VGA boot and VGA safe).
Network, and especially Firewall stuff on SP2, would bring lots of other components.
Anything GUI related that is not for CMD support. E.g., some control panel applets and etc. that're brought in by a dependency
checker.

And of course you'd want to turn off automatic dependency checking option.
 
The 009 key is not there when loading the software hive offline.
So, I need to figure out if the Windows NT Session Manager loads this key
and its data from a file saved on the disk? Or if it is possible to prevent
the Windows NT Session Manager to exclusively lock this key. Any Microsoft
people reading this? Andy?

Thanks for the information about the footprint reduction.
I removed the unnecessary hardware components and the result was better.
12,90MB / 17,92MB (compressed/uncompressed)
In a zip archive it ended up at 7,79MB.

I found the information about how to build the 5MB kernel image in
documentation.
Here is the link, and sorry for opening my big mouth before checking the
documentation
http://msdn.microsoft.com/library/d.../xeconbuildingkernelbaselineconfiguration.asp
 
No answers. I guess the MS people are busy working on the Feature Pack 2007 :-)
Thanks for the LIVE webcast yesterday! The Feature Pack will be of great
help in future developments.

If there is anyone out there that has idea on who to solve the issue with
the performance counter bug on already deployed device please let me know.
(see previous posts for details)

Thanks
 
Hmm.. I did reply to this thread yesterday. Don't know why the post didn't get through :-(
Here is what I said there:


Per,

18Mb is much better, isn't it? :-) I am sure you can get it even more reduced in size.

Regarding the 009 key.. Lets try a few more things:
- Check out the permissions on that key (use regedit at runtime). Make sure the account [or the group] you logged in under is
listed there.
- At runtime, please delete all perf?009.dat files under \windows\system32 directory (perfc009.dat, perfd009.dat, perfh009.dat,
perfi009.dat). Reboot and verify the 009 key (it is either going to disappear or you won't have perf counter related problems)
- Are you running English image? (must be English since you have got the 009 language id key at run time)
 
Back
Top