And the winner of must un-useful error message of the day goes to "The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly"

An interesting one that has just reared its head on our K2 [blackpearl] production server.

It only seems to happen when you start a freshly deployed workflow for the first time… the events in the order they happen seem to be

  1. Create, or modify an existing workflow
  2. Deploy
  3. Start the new workflow
  4. … nothing happens
  5. … still nothing happens
  6. Check error log - "The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly" in the K2 [blackpearl] management console error log (Shown in Figure 1 below)
  7. Scratch head…. and investigate some more…
  8. … give up investigating
  9. Start the new workflow (again)
  10. … IT WORKS.. no errors in the log…

and repeat for every new instance of a workflow deployed… It doesn’t seem to matter if it’s a brand new one or an update of an existing one.

Performance Counter Issue
Figure 1: A picture of the error

Have anyone seen this before? I think I will log it with the K2 support team…

Some preliminary investigation points to the fact that it is not very descriptive about the error, and it really means is that the Performance Object Category does not exist.

I’m referencing R. Engberg’s blog by the way :-)

Interesting one… if you have any advice, do leave a comment as it is an unwanted feature of our production server!

SpittingCAML




You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 Responses to “And the winner of must un-useful error message of the day goes to "The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly"”

  1. Johnny Fang Says:

    From what I see, this is a generic MS error that gets thrown when the performance counter you are trying to create it not there.

    So far I have seen this twice and it was an intermittent error.
    1) Customer had a corrupted VMWare environment. Resetting up solved the issue.
    2) Customer had a locked down environment where the IT security policies removed the message queue counters.

    I would try looking further in the event logs to see if there is additional information that might give clues on what is causing the failure.

  2. SpittingCAML Says:

    Hi Johnny, thanks for that.

    It’s not VMWARE related as this is our production server, however, it’s interesting that you’ve got some evidence that VMWARE environments can become corrupted as this is what we use as our virtualisation technology.

    I think you could be on to something with the security policys… what should I be looking for in the event logs, there’s nothing obvious otherwise I would have included it as part of this post.

  3. Johnny Fang Says:

    Normally there should be an error correlating to the performance counter error. It should also state the name of the counter that is having the error. This normally makes it easier to trace.

    The other thing is that if you are running a custom OS sysprep image, it might be some configuration or lock down in the image that is causing the problem. I have seen a couple of cases where there were strange OS issues when the sysprep image is not done right. i.e. they install a bunch of software on it first and then do the sysprep.

  4. SpittingCAML Says:

    I’ll check with our corporate image team as they are responsible for producing the build of the server OS. I’ll also have a word with the security guys who set the policies for our AD users.

    many thanks for your help

  5. SpittingCAML » The "The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly" saga… Part 2 Says:

    [...] We’ve looked into this in much detail… this is a continuation of a previous blog entry [...]

  6. Conrad Koekemoer Says:

    This issue seems to be related to WF performance counters not properly loaded on the K2 server.

    Run the following:

    lodctr “c:\windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\PerfCounters.ini”

    from within a cmd shell on the relevant server.

Leave a Reply