Configuration records may incorrectly contain additional dependencies when Symantec Endpoint protection is in use

Technote (troubleshooting)


Problem(Abstract)

When performing builds using IBM Rational ClearCase build auditing tools (clearmake, omake, or clearaudit), targets built by executing tools that are themselves under source control may include additional executables in their configuration records that were not actually executed during the build.

Cause

This issue has been observed when Symantec Endpoint Protection 12.1.1101.401 is used to secure the build host.

Diagnosing the problem

To verify that the issue is present is to analyze the following items:

  • Makefiles

  • Tools used during the build -- do those tools in turn execute others? For example, the GNU C compiler "cc" executes the C preprocessor and other tools as part of building the target object file.

  • Configuration records for built items.

A configuration record that exhibits this problem may have one tool listed in the build script, but multiple tools listed in the dependency list. For example:

    ----------------------------
    Derived object: \vob1\Mydir\mytarget.xyz@@1-Jan-13.16:16.4531
    Target mytarget.xyz built by user1.group1
    Host "BuildHost1" running NT 6.1 (i586)
    Reference Time 1-Jan-13.16:16:34, this audit started 1-Jan-13.16:16:35
    View was ccviewsvr:E:\Views\user1\user1_view.vws [uuid 11111111.22222222.3333.de:ad:be:ad:de:ad]
    Initial working directory was X:\user1_view\vob1\Mydir
    ----------------------------
    MVFS objects:
    ----------------------------
    directory version      \vob1\.@@\main\37                           <1-Jan-13.10:23:24>
    directory version      \vob1\Mydir@@\main\8    <1-Jan-13.16:16:10>
    directory version      \vob1\Mydir\bin@@\main\15 <1-Jan-13.10:34:37>
    version                \vob1\Mydir\bin\firsttool.exe@@\main\1 <1-Jan-13.10:31:43>
    version                \vob1\Mydir\bin\secondtool.exe@@\main\1 <1-Jan-13.10:31:52>
    version                \vob1\Mydir\bin\thirdtool.exe@@\main\1 <1-Jan-13.10:34:37>
    derived object         \vob1\Mydir\mytarget.dep@@20-Dec.14:20.4527 [referenced derived object, in makefile]
    version                \vob1\Mydir\mytarget.dep2@@\main\1 <1-Jan-13.10:35:42> [in makefile, primary dep]
    derived object         \vob1\Mydir\mytarget.xyz@@1-Jan-13.16:16.4531 [new derived object]
    ----------------------------
    Variables and Options:
    ----------------------------
    ...
    ----------------------------
    Build Script:
    ----------------------------
    bin\thirdtool.exe --dep1=mytarget.dep1 --dep2=mytarget.dep2 --output=mytarget.xyz
    ----------------------------

Once suspect objects have been identified, the only tool that appears useful to further diagnose the issue is Microsoft Process Monitor. A remotely-hosted dynamic view is needed for further diagnosis.

Note: Process Monitor is currently not compatible with operations performed in locally hosted dynamic views. A stop error (often referred to as a "Blue Screen" or BSOD) may occur if Microsoft Process Monitor is used while ANY operations are occurring in locally-hosted dynamic views.

Once a process monitor log has been collected, filter the output to:

  • include ONLY operations performed by the current command processor (usually "cmd.exe").

  • include ONLY operations whose path ends in the extension of the unexpected tool (it may not be, but usually is, ".exe").

  • exclude operations involving UNC paths that include the view server name. This prevents container paths from clouding the issue if some of the "extra" tools in question are view-private objects built in previous build steps.

If this issue is present, process monitor will show results resembling this "ReadFile" call coming from the command processor:

    Date & Time: 5/7/2013 8:16:48 AM
    Event Class: File System
    Operation: ReadFile
    Result: SUCCESS
    Path: X:\user1_view\vob1\Mydir\bin\firsttool.exe
    TID: 4792
    Duration: 0.0046767
    Offset: 0
    Length: 32,768
    Priority: Normal

Since these anomalous read operations were coming from the command processor, a closer look at the stack showed that nearly half of the function calls in the stack are from within Symantec Endpoint protection.

Removal of Symantec Endpoint Protection from a non-production test system that was able to reproduce the issue eliminated the anomalous read operations, and the configuration records for those targets no longer contained "extra" dependencies.

Resolving the problem

The current resolution to this issue is to update Symantec Endpoint Protection to include at least 7.8.0.10 of the Symantec "sonar driver". This update appears to be in versions of Symantec Endpoint protection 12.1.3.x and later.

IMPORTANT NOTE: At this time, there are additional unresolved issues with Symantec Endpoint Protection that may block implementation of the above resolution. See the "Related information" link below for more information.


Related information

STOP Errors with Symantec Endpoint protection

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Rational ClearCase
Clearmake - Clearaudit - Omake

Software version:

7.0, 7.0.1, 7.1, 7.1.1, 7.1.2, 8.0, 8.0.1

Operating system(s):

Windows

Reference #:

1641935

Modified date:

2013-06-25

Translate my page

Machine Translation

Content navigation