One fine day the SAP system on our development server did not come back after an overnight offline backup. The guys tried a lot but it wouldn't start. Trying to start it from the command line told us that the mfc71u.dll was not present in C:\WINDOWS\system32. We restored the file from last nights backup and the SAP system started perfectly.


Now on a regular PC generally nobody goes in C:\WINDOWS\system32 and deletes files on a fancy and this was a heavily restricted SAP server with only the SAP and the OPS team having access. System logs didn't not indicate any unwanted activity. The only activity was the installation of Symantec EndPoint Protection Manager client, but this was a week back. Also this deployment had been tested on 5 test server previously without any issue.

The server's application event log indicated that Symantec EPM installed successfully. Still I got the boys to check the log created by Symantec EPM. This is what we found in the installation log. 

Info 1603.The file C:\WINDOWS\system32\mfc71u.dll is being held in use by the following process: Name: sapstartsrv, ID: 10572, Window Title: (not determined yet).  Close that application and retry.
MSI (s) (58:10) [15:31:12:215]: Note: 1: 2727 2:  
...
MSI (c) (C8:88) [15:31:12:215]: No window with title could be found for FilesInUse
MSI (s) (58:10) [15:31:12:215]: Doing action: uExtBeginUninstallImmediate.6500F9C2_37EA_4F25_A4DE_6211026D9C01
Action ended 15:31:12: InstallValidate. Return value 1.
MSI (s) (58:28) [15:31:12:231]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI324.tmp, Entrypoint: _BeginUninstallImmediate@4
... 

MSI (s) (58:10) [15:31:46:590]: Executing op: SetTargetFolder(Folder=C:\WINDOWS\system32\)
MSI (s) (58:10) [15:31:46:590]: Executing op: FileRemove(,FileName=mfc71u.dll,,ComponentId={3AC4AA25-A28A-4F09-826A-30CA0A620F35})

So it looked like Symantec EPM client install had removed the file post installation. Surprisingly we did not notice this behaviour on any other PC/Server. 

Fair to say sometimes you find the cause of a problem in the least expected places.

5 comments:

cheezwhizze said...

Thanks for posting. We had the same issue.

cheezwhizze said...

As it turned out, we had a similar, but different issue. Symantec Endpoint Protection 11 INSTALLED the mfc71.dll on our server, but DID NOT install mfc71u.dll. We had a utility program which was working fine (apparently using mfc42.dll and mfc42u.dll) which now apparently requires mfc71u.dll to function. Again, the solution was obtaining a working version of mfc71u.dll, though I was a bit nervous about versions, so I stuck it in the folder with the program in question and not in the \windows\SysWow64 folder (32-bit app on a 64-bit 2003 server).

cheezwhizze said...

Sorry, one more clairifier to the above--the utility in question now requires mfc71u.dll apparently *because* mfc71.dll was installed by SEP11. I'm guessing they are companion dlls and the install of one somehow alerts the calling program that there is a newer version to use.

Sandor Kligan said...

I am using another way to fix dll errors. I am tired from reinstalling all these microsoft visual c++ and now i am downloading strictly my file from the http://fix4dll.com/msvcp140_dll. It's easier.

for ict 99 said...

Great Article
Final Year Project Domains for CSE
Project Centers in Chennai



JavaScript Training in Chennai
JavaScript Training in Chennai