IIS - E10 w3wp.exe Worker Process Operations

I was trying to look more in-depth at the IIS w3wp.exe worker process and I ran across some interesting activity on our Epicor w3wp.exe Process. Within the Process Monitor, I’m seeing a lot of “CreateFile - NAME NOT FOUND” and “QueryOpen - FAST IO DISALLOWED” entries (Like Hundreds of Thousands of them if I’m looking at this correctly…?) in Process Monitor. Please see image below.

My Process Monitor Filter:

image

And the events found number just keeps increasing…

image

When I go to C:\inetpub\wwwroot\ERP\Server\Assemblies\ folder I cannot see the, for example, Ice.Triggers.UD103A.dll file anywhere…so I do understand why it is saying “NAME NOT FOUND” but how can I figure out where this call to the Ice.Triggers.UD103A.dll file is coming from within Epicor?

We are using the UD103\UD103A tables for something we call our “Line Tracker”. Is the problem that our Line Tracker Customization is referencing the Ice.Triggers.UD103A.dll file within it (possibly through a Library or “using” statement) and possibly it doesn’t exist anymore (or was renamed with the newer version of Epicor?)

I ran the Process Monitor in our Test Epicor environment with the same filters and I don’t see any of these “NAME NOT FOUND” entries or “FAST IO DISALLOWED” entries - I’m sure because no one is using that Test Environment right now.

Just something I stumbled across that I was curious about where so many entries were coming from and how to stop them.

Thank you so much for any help or thoughts anyone can provide!
-Heather

I would use that customization in the test environment to confirm that it is the source, then, if it was confirmed to be the source I would comment out / remove functionality until that error is no longer produced. That will tell you where in the code the issue is. (If the developer of the customization is around they might be able to guess the location and skip that step.)

1 Like

I think Data Directives are implemented via triggers. Is it possible that a Data Directive was used then removed? (Not sure why it would be in a using statement though… :thinking: )

1 Like

I might be completely off with the using statement idea. I was just wondering where in Epicor the C:\inetpub\wwwroot\ERP\Server\Assemblies\Ice.Triggers.UD103A.dll call would come from? I’m not sure about the Data Directive but I can look and ask. Thank you guys for the ideas.

Edit: and I’m not just getting Ice.Triggers.UD103A.dll entries, I’m getting other “NAME NOT FOUND” entries as well for all of these:

C:\inetpub\wwwroot\ERP\Server\Customization\Externals\Erp.Triggers.PartQtyDeferred.dll
C:\inetpub\wwwroot\ERP\Server\Assemblies\Erp.Triggers.PartQtyDeferred.dll

C:\inetpub\wwwroot\ERP\Server\Customization\Externals\Erp.Triggers.PartBinDeferred.dll
C:\inetpub\wwwroot\ERP\Server\Assemblies\Erp.Triggers.PartBinDeferred.dll

C:\inetpub\wwwroot\ERP\Server\Customization\Externals\Ice.Triggers.ChgLog.dll
C:\inetpub\wwwroot\ERP\Server\Assemblies\Ice.Triggers.ChgLog.dll

C:\inetpub\wwwroot\ERP\Server\Customization\Externals\Ice.Triggers.UD27.dll
C:\inetpub\wwwroot\ERP\Server\Assemblies\Ice.Triggers.UD27.dll

etc…

1 Like

So “triggers” DLLs are used for Data Directives

Epicor looks to see if they have a DataDirective for a particular table all the time since you could add a new DD at any point.

So that’s part of the standard epicor process I wouldn’t worry about it too much.

Basically its going Hey do I have a data directive for this table? no?.. oh okay cool!

1 Like

Interesting! Ok, great! So it’s not anything that we’ve created in error or need to fix on our end. Thank you for explaining that! :slight_smile: