My company is having an issue. At the moment, we are testing APPS10 with an expected go live date in November. Since testing, with a very limited set of users, we have noticed that some are getting .dll errors for pages they frequent. One day during testing they can see it, the next they can’t. In apps 9, the user could technically cause a .dll error if they cancel out of the download at the bottom when they first go to the page. In 10, there is no cancel button available when downloading the package to view the page (good improvement). We did some testing. While troubleshooting I moved the .dll file that the page was complaining about to a separate folder > went to “download all packages” > IFS realized it was missing 1 package and downloaded it > but we still can’t see the page until we delete everything out of the 2.0 folder. The only help I’ve gotten from IFS is to clear the cache which is essentially the equivalent of an uninstall/reinstall of the instance since it deletes the .exe file stored in that folder. We have an open ticket with IFS but so far, clearing the cache is their only solution. We’re worried that when we go live we’re going to have to remote into desktops constantly to mitigate this caching error and essentially, halt production in the process. We have very little people in our 10 testing environment and so far we’ve had about 15 users get the .dll error, some multiple times (and in multiple environments, 9 included) even after downloading all packages. Has anyone else experienced this when testing apps 10?

@klorimer, @asmackenzieWe still get DLL errors but not as often. This is what we check when we remote into a users computer:Is IFS pinned to the taskbar? If it is, unpin it. We noticed not all users can pin the icon to the task bar. IFS is saying this is a windows functionality so we don’t have an answer for why some can and others can’t. If the application is pinned, this hasn’t been verified BUT I’m assuming that the version pinned to their taskbar hasn’t been updated, meaning the manifest is old. Again, this is not verified, I’m just trying to make sense out of it. We had the same users getting DLL errors weekly, sometimes multiple times a week and the common thread was that IFS was pinned to the taskbar.After the user unpins OR the user verifies that it is not pinned, have the user restart their machine.After the machine is back online, tell the user to NOT open IFS.Remote in andexecute the following command in CMD window as administratorrundll32 %windir%\system32\dfshim.dll CleanOnlineAppCacheWe expect DLL errors after applying patchesbecause we’re effectively rebuilding the manifest and some users might not get all the pieces they need.Another thing you can ask of your users is how often they cleanly shut down their machines. The above command is a default windows command that clears the .net cache. The .net cache should be cleared regularly without manual intervention when the user shuts their computer down on a regular basis but if they haven’t shut down in a while, they could have issues.I hope this helps!I feel like I could troubleshoot this in my sleep (LOL) we had so many issues when we updated to 10 and an open case with IFS for a couple of months.

.DLL Error in 10 even though File is Present

Page 1 / 1

I would do a test where you clear the cache and then run either APPS 9 or APPS 10 only for a period of time.

The issue could be caused by running both applications at the same time or by not clearing the cache between switching versions.

@Anna Is this issue coming up for specific screens /DLL or is it applicable for any screen. It would be good to look at where the issue is firing up to see whether it comes up for specific screens most of the time.

In addition to what @CallumW mentioned it’s probably worth checking whether the Anti virus/malware in the machine is putting certain files in to quarantine for some reason. If a user has no issues one day and issue the next, it’s possible that a DLL that was in the cache was removed by an external process like the AV

@Anna, Hi Anna, we have just moved to Apps10 and we are encountering the same issues with DLL as you are describing. Have you been able to find out what was causing it? Any improvements?

We have received the same recommendations from IFS about deleting the cache but we cannot carry on this way. They said as well that we might be running an older version of clickonce…

Any help will be appreciated,

Kind Regards,

Anne-Sophie

We are currently testing Apps10 and are experiencing dll issues, as stated in comments from other users to continually have to delete cache is not acceptable. We need to get a better understanding why this continues. We are also experiencing this in Apps 8 and there is no common screens theme when the dll not found error occurs

Hi, we still have the issues and after logging a case with IFS, we never received a satisfactory answer. It is very random and cannot be explained by an antivirus issue, we have checked several times. IFS needs to provide an answer as the DLL system is part of the architecture of the system. We hope this post will be answered by IFS as we have been recommended to use Community to flag issues.

Thanks and Kind Regards,

Anne-Sophie

Hi @Anna & @asmackenzie

Did you ever get any resolution to the dll not found issue. We have just gone live with VS10 and our users are experiencing this everyday and we have cleared cache, downloaded packages and still nothing helping the problem.

@klorimer, @asmackenzie

We still get DLL errors but not as often. This is what we check when we remote into a users computer:

Is IFS pinned to the taskbar? If it is, unpin it. We noticed not all users can pin the icon to the task bar. IFS is saying this is a windows functionality so we don’t have an answer for why some can and others can’t. If the application is pinned, this hasn’t been verified BUT I’m assuming that the version pinned to their taskbar hasn’t been updated, meaning the manifest is old. Again, this is not verified, I’m just trying to make sense out of it. We had the same users getting DLL errors weekly, sometimes multiple times a week and the common thread was that IFS was pinned to the taskbar.
After the user unpins OR the user verifies that it is not pinned, have the user restart their machine.
After the machine is back online, tell the user to NOT open IFS.
Remote in and execute the following command in CMD window as administrator rundll32 %windir%\system32\dfshim.dll CleanOnlineAppCache

We expect DLL errors after applying patches because we’re effectively rebuilding the manifest and some users might not get all the pieces they need.

Another thing you can ask of your users is how often they cleanly shut down their machines. The above command is a default windows command that clears the .net cache. The .net cache should be cleared regularly without manual intervention when the user shuts their computer down on a regular basis but if they haven’t shut down in a while, they could have issues.

I hope this helps! I feel like I could troubleshoot this in my sleep (LOL) we had so many issues when we updated to 10 and an open case with IFS for a couple of months.

Thank you @Anna , we will give this a go. A bit disappointed that IFS can not be more specific about the problem and also have a better resolution than just clear cache.

Regards

Karen

@klorimer, @asmackenzie @Anna

Adding the Solution found by a Customer : use of Firefox instead of Chrome solved their problem.

@Dominique Husson , in case of NGE, it was switching to Edge that fixed the problem.

Many Thanks,

Anne-Sophie

Reply

Did you find what you're looking for? If not:

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded