C:\Windows\system32\sysfer.dll

[Migration User]

I don't need everyone jumping on -board telling me this is a SEP file or that it is part of NTP.  I know all that already.

I don't need to know that if I uninstall NTP the error messages generated will go away, I know that too.

What I do need, is to know why, after 2 years, this file file is still creeping up and giving errors:

* * * * * * * *

Event ID 6281 - Microsoft Windows Security Auditing.

Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.

File Name: \Device\HarddiskVolume2\Windows\System32\sysfer.dll

 * * * * * * * * *

I have this all over my network in all of my security logs... 

* * * * * * * * * *

SEPM server is 12.1 RU1 MP1

SEP 12.1 clients 12.1 RU1 MP1

All workstations are Windows 7 x64 Enterprise

 

[ℬrίαη]

This is probably a question that only support will be able to answer.

[Migration User]

no as resolution but thought might give some insight , this is not mentioning anything about sysfer

http://support.microsoft.com/kb/977519

[Migration User]

This is most likely due to application and device control (ADC) injecting sysfer.dll into protected windows processes. A possible workaround for this would be to make exclusions for the following processes in your ADC policy.

%[SYSTEM]%\audiodg.exe (Audio Device)
%[SYSTEM]%\mfpmp.exe (Media Foundation Protected Pipeline)
%[SYSTEM]%\werfault.exe (Windows Problem Reporting)
%[SYSTEM]%\werfaultsecure.exe (Windows Fault Reporting)
%[SYSTEM]%\wermgr.exe (Windows Error Reporting Manager/ Windows Problem Reporting)

[Migration User]

http://community.spiceworks.com/windows_event/show/1290-microsoft-windows-security-auditing-6281

[Mithun Sanghavi]

Hello,

I agree with Cameron's Suggestion. "Thumbs up"

In case, if that does not work, I would request you to create a Case with Symantec Technical Support.

Symantec is aware about this issue. You could also PM me your Case #.

 

[Migration User]

Anything new regarding this?

 

[Migration User]

Ok, so I'm having this issue on my machines as well. I did have the default policy that is created when SEP is installed defined, but it was never enabled. I have since deleted the policy entierly trying to get rid of these errors, but still get them. Do I need to redeploy the client in order to get the errors to stop?

Eric

[Migration User]

I have the same quesiton as Fdaniel - I am seeing such things in logs, but worse, application error event ID 1000 and this info - SYSFER.DLL and LOGONUI.EXE not playing well together.

SEP RU1  (can't get RU1 MP1 to install on several computers - fails quite a bit)

Here is the error ->

Faulting application name: LogonUI.exe, version: 6.1.7601.17514, time stamp: 0x4ce79505

Faulting module name: SYSFER.DLL, version: 12.1.1000.157, time stamp: 0x4eae0055

Exception code: 0xc0000005

Fault offset: 0x00034a79

Faulting process id: 0x1754

Faulting application start time: 0x01cdb949046ad3aa

Faulting application path: C:\Windows\system32\LogonUI.exe

Faulting module path: C:\Windows\System32\SYSFER.DLL

 

[Migration User]

I have a case registred for this. It is something with the ADC policy because you will not receive it if you uninstall that part. I´ll update this thread when i get more info from Symantec.

Daniel

[Migration User]

Great - I can help with any info needed as well, I'm seeing CONSTANT since we moved to RU1 last spring, it's crashing with LOGINUI.EXE almost daily.

This is another example of a Windows log - and I can furnigh WER files as needed, although I have no way to read them!

Fault bucket , type 0

Event Name: APPCRASH

Response: Not available

Cab Id: 0

Problem signature:

P1: LogonUI.exe

P2: 6.1.7601.17514

P3: 4ce79505

P4: SYSFER.DLL

P5: 12.1.1000.157

P6: 4eae0055

P7: c0000005

P8: 00034a79

P9:

P10:

Attached files:

These files may be available here:

C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_LogonUI.exe_3b7496c59cf4577197b9ebe1e7ab584286b74_0e311380

Analysis symbol:

Rechecking for solution: 0

Report Id: 94da9f27-253c-11e2-9e23-020086ae6894

Report Status: 4

[Migration User]

Hope to hear soon.

Uninstalling or removing app and device control is not an option. It's one of the bigger reason we even have SEP.
Imagine - your car misbehaves and you are required by your license or restricted to an automatic transmission. The mechanic says "yeah, known issue - you can get around that by taking out the transmission". Or "just get a car with a stick, they won't do this".

How lame - Uh, yeah - cripple the app and live without half of it? Then what's the point?  Hey, that gun will be very quiet if you never pull the trigger. I just love replies like "simply disable" or "just uninstall". Anyone given any thought to that part being a requirement for even owning such an application?

It's useful for proving the point of "this is the part that is causing it" but as a solution, please, don't even suggest it. 
App and device control is one big reason we've been totally virus and malware-free since March of 2011 (and it's now November 2012), and a reason I can assure documents are not walking out of here easily.

This is what happens - user hits Ctrl-Alt-Del, the computer has just been handed a top priority call to the OS to drop everything and pay attention, no hesitation. However, hesitate it does, and at times, it totally prevents the user from gracefully logging out, locking the PC or restarting it, instead forcing a power-button hit.

Log Name:      Application
Source:        Application Error
Date:          11/8/2012 4:41:46 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      xxxccyydddf.domain.gov.state.xx.us
Description:
Faulting application name: LogonUI.exe, version: 6.1.7601.17514, time stamp: 0x4ce79505
Faulting module name: SYSFER.DLL, version: 12.1.1000.157, time stamp: 0x4eae0055
Exception code: 0xc0000005
Fault offset: 0x00034a79
Faulting process id: 0xd98
Faulting application start time: 0x01cdbe02380edbde
Faulting application path: C:\Windows\system32\LogonUI.exe
Faulting module path: C:\Windows\System32\SYSFER.DLL
Report Id: 793a6bbe-29f5-11e2-afea-001b783f9390
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2012-11-08T22:41:46.000000000Z" />
    <EventRecordID>4876</EventRecordID>
    <Channel>Application</Channel>
    <Computer>xxxccyydddf.domain.gov.state.xx.us
</Computer>
    <Security />
  </System>
  <EventData>
    <Data>LogonUI.exe</Data>
    <Data>6.1.7601.17514</Data>
    <Data>4ce79505</Data>
    <Data>SYSFER.DLL</Data>
    <Data>12.1.1000.157</Data>
    <Data>4eae0055</Data>
    <Data>c0000005</Data>
    <Data>00034a79</Data>
    <Data>d98</Data>
    <Data>01cdbe02380edbde</Data>
    <Data>C:\Windows\system32\LogonUI.exe</Data>
    <Data>C:\Windows\System32\SYSFER.DLL</Data>
    <Data>793a6bbe-29f5-11e2-afea-001b783f9390</Data>
  </EventData>
</Event>

As much as I like version 12.x.xx.xxxx.xx.xxxx.xx.xx I have to honestly say, no exaggeration, this has been the most troublesome version I've ever run into save for SAV CE 7.00  (and I've dealt with NAV and SAV and SEP since NAV 2.0 back in the early 90s) 
We didn't have these problems with the 11 series - the rollouts, updates, upgrades, all very smooth. Nothing but trouble even rolling out RU1 MP1 the last few days - the phone was literally constantly lit up this AM as users were concerned that after the reboot - it took from 15 to 60 minutes for them to regain control. And then their inability to lock or logout isn't making them very fond of this series.  I wonder - if bugs like this are at play even in the updates/upgrades?
Can't tell as the Windows logs are also frozen right after a SEP upgrade!

[Migration User]

I have had these exclusions almost from day 1, however, I just tried something and found out something else....

For us, in Windows 7, "SYSTEM" doesn't fly. Interesting - this means those exclusions, although they have been there for a very long time, have not worked since Windows 7 was rolled out here.

I tried on a couple of computers to get to those files via the %system% variable, and Windows said "not found". But when I tried using this
%WINDIR%\system32
It went right in.
I tried system, system32 and all variations I could think of, but %system% just didn't work.
So, I modified the policy using instead the above path of %WINDIR%\system32\filename.exe and we'll see what happens.  I can't blame SEP on that as it was giving me fits just at the OS level attempting to get to the system32 folder. So if I can't, then SEP can't......
 

[Migration User]

Upgrading to SEP12.1RU2 solves this.

[Migration User]

Good to know - hope to test that theory soon.

 

[Mick2009]

The information and example in this new article may help to overcome such crashes:

Creating Application Control Exclusions in Symantec Endpoint Protection 12.1
https://www-secure.symantec.com/connect/articles/crreating-application-control-exclusions-symantec-endpoint-protection-121
 

With thanks and best regards,

Mick

[Anslem Alexander]

Hi, To resolve "C:\Windows\System32\SYSFER.DLL" file issue you should follow steps at the time of fresh installation of SEP 12.1 1. Give full permission to power user and administrator to folder "C:\Windows\System32" and Security for temporary basis than install SEP client. 2. After completion of installation, resart system. 3.Revert back all permission as before. 4. restart the system. Now check it will work properly. same steps we are following in our invironment. Hope it will helpfull for you.

[Migration User]

Administrator already has all full permissions by virtue of being ADMINISTRATOR. It can't get any better than administrator already has. In fact, Administrator has more power and rights even that a domain administrator as far as software on the local machine.

Power User is often removed or disabled as it's a dead concept - but in any case, still there or not, power user should have no impact on anything at all as no one is ever a member of power user, especially SERVICES of any sort.
Services either run as the local user, as SYSTEM, and so on. Power user isn't used by anything any longer.
Power user is a legacy concept and it's been years since I've seen it have any impact on anything at all. You can actually totally remove that group and not suffer ill-effects.

Take a look at this - from what Microsoft states here, there's no logic in making such changes.... in other words, how can you possibly grant more rights to administrator than administrator already has if administrator has complete and unrestricted rights? There's nothing more to grant or give.

 

 

[Anslem Alexander]

Thanks for your suggetion. There are many organizations which is not allowing default administrator login because of security compilance. They uses power user. If you already using local administrator then no need to give permission. But if you are using power user than it will required. If you having any better solution you can provide us. we will follow you and implement in our environment also.