• State Suggested Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 13 subscribers
  • Views 432 views
  • Users 0 members are here
Options
Related

Warning in Log viewer related to the BRO component

Jakob Agustsson

Hi,

I made some minor changes to a Area object which resulted in a error in the log  - "DRE51006 - CBaseRuntimeObject::InternalSetAttribute - Sets are not allowed on a quarantined object." It relates to a component called BRO. What does the BRO component related to? and what does it mean that a object becomes quarantined?

note: "DRE51006" is the name of the area object. 

  • 0

    Most likely a script on this area object DRE51006 is running into an exception which is resulting the object quarantine. Review the scripts on this are object to identify the problematic script and fix the code causing exception.

  • 0 in reply to Srinivasa Chamala

    Hi Mr. Srinivasa, thank you for your help.  I ended up restoring a backup.  This definitely had to do with a script but I wasn't able to identify what was wrong with it.

    The case was like this, there was an inherited script running on the area object. It was a very simple script. It's purpose was to change a value on a string attribute, it was running periodically every 10 minutes but it was not locked so any changes to that script were not propagated. Derived instances from the area template where the script was defined were around 200. I needed to change the original value for the string attribute for all the area objects.  So what I did was locking the script in the template and propagating it to all its children with a new string value defined.  

    When deploying one of the area objects, (DRE51006) it got quarantined. I tried unlocking the script and changing the string value to the previous value. But that didnt help.

    I did some more work trying to fix it. Here is a screenshot with more comprehensive results when deploying more of the  area instances with the propagated changes. This shows all warning and errors related to the deployment 

     

    I gave up debugging it and restored a backup.  I guess sometimes it is not possible to identify the root cause. But thank you for your help and taking time to answer!

  • 0 in reply to Srinivasa Chamala

    Hi  just checking with you again related to a error in my log, which is maybe related or maybe not.  

    The error refers to a path:  Unknown error 0xC0000005 (c0000005) caught at line 3371 in ScanGroupRuntime.cpp (in E:\ADO\Work\65\s\src\ScanGroup\ScanGroupRuntime\).  and a file ScanGroupRuntime.cpp  this path does not exist on the E-drive. So I am wondering, do you by any change know where this file could be located and also if you have any tips. Thank you kindly.

  • 0 in reply to Jakob Agustsson

    This looks like a C++ Error message, and I would believe the exception is not referring to a missing file on your drive, it just indicates the path in the 'unbuilt version' for the AVEVA Developer.

    So RnD would be able to make sense of this error.

    Ie. you don't have file PrimitiveRuntimeSupport.h in the path "D:\ADO\Work\48\s\SharedComponents\Internal\MagellanPublic\Includes\SDK\" either.

    For these kind of exceptions I would contact techsupport, but as a general discussion when it comes to quarantined objects they tend to be put in this state when the engine identifies a very bad exception.

    The mechanism for doing this is now well known to me and it is usually resolved by undeploying the object (or the corresponding engine) and deploy again. If the issue comes back then there is usually some code executed by the object that causes the issue, look for any 'non naitive'-scripting, such as references to imported dlls, .Net script libraries. etc.

    If you can not find any code to suspect, it might be some corruption of the object, I have managed to resolve this by exporting the instance to csv, delete it, and then import it again.

    If issue still remain I would believe the fastest way to resolve it is to contact techsupport, but be prepared to share your galaxy backup if this is not a known issue to them. 

    Also as a good practice is to use the try..catch in your scripts to at leas avoid any unmanaged exceptions, when working with external libraries, this will at least manage some of the issues, and is not a 100% inurement depending on what your script library actually does.

  • 0 in reply to Richard Köhlerstrand

    Hi Richard, I have random objects going in quarantine now so I am having a hard time identifying the root  cause will try to have my distributor create a support case.  I am basically experiencing this problem: 

    https://knowledge.insourcess.com/?title=Visualization_and_Supervisory_Control%2FApplication_Server%2FMaximize_%26_Optimize%2FTN_AppSvr196_Sets_Are_Not_Allowed_On_A_Quarantined_Object

© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.