• State Suggested Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 13 subscribers
  • Views 251 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. 

Parents
  • 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  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.

Reply
  • 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.

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