.Net Windows service failing to start on freshly-built box

[Mark]

Hi...

Someone asked me to look into why a .net windows service we use in a lot of
places was failing to start on a box he just had built fresh. It's running
W2k3 Web Edition Sp 2 with IE 8.

Since it's a production box, we don't have any of the debuggers installed
there, but it doesn't seem like the software is even firing up far enough to
do any logging.

Depends shows 2 missing dlls: IESHIMS.dll and WER.dll.

I haven't found anything definitive, nor any solution, but a lot of Googling
seems to point to the IE 8 installs messing things up. It introduces a new
version of MSHTML.dll/IEFRAME.dll with a dependency on IESHIMS.dll which
doesn't exist on the system.

Without a lot of debugging tools how does one prove it's the missing
unmanaged dlls several levels away from our softwre causing the trouble? And
what do we do about it?

Thanks
Mark

 

[Family Tree Mike]

Hi...

Someone asked me to look into why a .net windows service we use in a lot
of
places was failing to start on a box he just had built fresh. It's
running
W2k3 Web Edition Sp 2 with IE 8.

Since it's a production box, we don't have any of the debuggers installed
there, but it doesn't seem like the software is even firing up far enough
to
do any logging.

Depends shows 2 missing dlls: IESHIMS.dll and WER.dll.

I haven't found anything definitive, nor any solution, but a lot of
Googling
seems to point to the IE 8 installs messing things up. It introduces a
new
version of MSHTML.dll/IEFRAME.dll with a dependency on IESHIMS.dll which
doesn't exist on the system.

Without a lot of debugging tools how does one prove it's the missing
unmanaged dlls several levels away from our softwre causing the trouble?
And
what do we do about it?

Thanks
Mark

Do you possibly mean Windows 2008? Windows 2003 did not distribute IE 8, as
far as I can see.

As far as debugging, have you tried installing IE 8 in your development
environment?

 

[Mark]

IE 8 has started coming out in Windows Update, I think... I've seen it go by
on our xp development boxes, so I figure it's also on the update list for
2003. In any event, this 2003 box is running 2003.

The thing I find odd is that the Google posts I've found imply it was IE 8
-related patches to mshtml.dll that created the dependency on IESHIMS.dll and
WER.dll, yet on a fresh system neither exist in the system...

Thanks
Mark

 

[Jie Wang [MSFT]]

Hi Mark,

Does your service application EXE comes with a config file
(<app>.exe.config) and a win32 manifest file?

A few days ago there was another post talking about a known bug in Windows
Server 2003 that is related to the .NET application's config file and could
cause the application fail.

If that is the case, please refer to this blog post for a workaround:

http://blogs.msdn.com/junfeng/archive/2006/08/09/692996.aspx

If that is not the case, could you try the Process Monitor tool on that
machine to take a log of what the application is trying to access and we
may have a chance to find out what went wrong from the log?

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

This tool doesn't need installation, just extract and run.

You can add a condition filter before starting the application: Process
name is <your service application exe name>.

If you think it's okay to share the log file, you can upload it to SkyDrive
(http://skydrive.live.com) and share the link here. I'll take a look and
see what can be found.

Thanks,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mark]

Hi Jie Wang...

Thank you for your response...

This app doesn't have a config file. I did put Process Monitor on the
system and got some 30000 events; hard to filter through all the
path-not-founds when it's picking through the path.

I do notice that the exit status of our app is 0xE0434F4D (-532459699).
Found a couple of old articles saying this is the status when .net 1.1 isn't
installed properly.

If you'd like to see more of the log, I can get it uploaded...

Thanks
Mark

Hi Mark,

Does your service application EXE comes with a config file
(<app>.exe.config) and a win32 manifest file?

A few days ago there was another post talking about a known bug in Windows
Server 2003 that is related to the .NET application's config file and could
cause the application fail.

If that is the case, please refer to this blog post for a workaround:

http://blogs.msdn.com/junfeng/archive/2006/08/09/692996.aspx

If that is not the case, could you try the Process Monitor tool on that
machine to take a log of what the application is trying to access and we
may have a chance to find out what went wrong from the log?

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

This tool doesn't need installation, just extract and run.

You can add a condition filter before starting the application: Process
name is <your service application exe name>.

If you think it's okay to share the log file, you can upload it to SkyDrive
(http://skydrive.live.com) and share the link here. I'll take a look and
see what can be found.

Thanks,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mark]

Just to follow up this thread, someone went an uninstalled IE 8; to my
surprise it also backed down a rev of mshtml.dll and ieframe.dll, thus
removing the dependencies on IESHIMS.dll and WER.dll but leaving a couple
more unresolve references on IEFRAME.dll

Thanks
Mark

 

[Mark]

I think I found what was causing the problem, and it does seem to be related
to IE 8.

Around the times this app was running there were often UserEnv errors in the
application logs about being unable to resolve a couple of guids.

I googled the guids and it turned out to be some entries under
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\GPExtensions
{7B849a69-220F-451E-B3FE-2CB811AF94AE}
{CF7639F3-ABA2-41DB-97F2-81E2C5DBFC5D}

that appear to be related to IE 8. The reg entries get left even when you
uninstall IE 8.

Deleting these entries seems to clear up the issues with our .Net Windows
service...

Thanks
Mark

Hi Mark,

Does your service application EXE comes with a config file
(<app>.exe.config) and a win32 manifest file?

A few days ago there was another post talking about a known bug in Windows
Server 2003 that is related to the .NET application's config file and could
cause the application fail.

If that is the case, please refer to this blog post for a workaround:

http://blogs.msdn.com/junfeng/archive/2006/08/09/692996.aspx

If that is not the case, could you try the Process Monitor tool on that
machine to take a log of what the application is trying to access and we
may have a chance to find out what went wrong from the log?

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

This tool doesn't need installation, just extract and run.

You can add a condition filter before starting the application: Process
name is <your service application exe name>.

If you think it's okay to share the log file, you can upload it to SkyDrive
(http://skydrive.live.com) and share the link here. I'll take a look and
see what can be found.

Thanks,

Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jie Wang [MSFT]]

Hello Mark,

Good to know the service is up and running again.

Those two registry keys you mentioned seems to be IE 8's new feature
"Accelerators" related. Since I don't know if or not your service
application uses any IE components directly/indirectly, I can't say what
the root cause is at the moment.

However, I suggest you try to find out the root cause if this service is
going to be used for quite a long time in the future. The new Windows
Server 2008 R2 will come with IE 8 as part of the system; at that time,
when the server OS is upgraded the service will likely down again.

The exit code 0xE0434F4D usually indicates there was unhandled exception so
the process exits.

If you can make changes to the service's code, you may want to make use of
the AppDomain.UnhandledException Event to log the unhandled exception so it
will be easier to find out the root cause.

Best regards,

Jie