This is the Linux content page of the CL Wiki Service Desk Knowledgebase. Its purpose is to provide information to the Service Desk team on how to handle problems and requests about this CL service. If you are involved with the provision of this CL service please feel free to add to the knowledge about that it. The Diagnostic Codes under 38 CFR ยง 4.73 for shoulder and arm conditions are split into six groups based on the limitation of motion of the different affected muscles. All of the criteria include severe, moderately severe, moderate, or slight and corresponds to a disability rating ranging from 0 to 40 percent. The FAQ addresses common questions in terms of features, usage, as well as support related topics. All sections link to corresponding articles. For detailed documentation use the search bar or write a ticket to support@anydesk.com. Show/hide all answers.
-->This article introduces how to troubleshoot common permissions and security-related issues in ASP.NET.
Original product version: ASP.NET
Original KB number: 910449
Useful tools
Before you attempt to fix anything that is broken, you need to familiarize yourself with a few tools, which will help you narrow down the issue. In our case, we would be interested in tools like FileMon, RegMon, and Security Auditing. For more information about FileMon, see FileMon for Windows v7.04.
For more information about RegMon, see Windows Sysinternals.
Drill down to isolate the problem
- Has the application ever worked? If yes, then what changed that could have made the application break? It's possible that software updates or security updates were applied on the server. A code rollout also could have caused the issue.
- Do simple .html and .asp pages serve from IIS?
- Was the application migrated to a different version of IIS?
- Do other ASP.NET applications on the server fail with the same error? Is this the only application that fails?
- Does the issue occur for all users or for only specific users?
- Is the issue reproducible while browsing locally on the Web server, or is it reproducible for only a few clients?
- If you are using impersonation, then does the impersonated user have the necessary access to the resource?
The above questions are useful in order to diagnose a problem. If you are posting your issue on any of the ASP.NET forums, and if you already have the answers to most of these questions, then it's likely that you will get a quick pointer or solution to your problem. The key is to post the whole ASP.NET stack trace error, if applicable, instead of saying 'I am getting an Access Denied error while trying to run my ASP.NET application. Can anyone help?' It's much easier for someone to look at the stack trace and give you pointers when they can see a complete error message. So you need to ask yourself...
What is the exact error message?
The first question we ask customers is, 'What is the exact error message?' If you have a clear description of the error message thrown by the Microsoft .NET Framework, you can skip this section. If your application masks the actual error message and gives you a friendly error message instead, such as, 'An unexpected error has occurred. Contact the website administrator for details,' it's not of much use to anyone. Here are a few steps, which will help you get the actual error message.
Locate and open the Web.config file in the application directory and change customErrors to mode='Off'. Save the file, and reproduce the problem.
It still might not be possible to see the actual error message after following the above step because of custom event/error handling done by the application developer. You can try to locate the Application_Error event in the Global.asax file and comment out any code that uses the
Server.Transfer('Errors.aspx')function to go to a custom error page.
Once you get the actual error message, read it to determine if the error is caused by missing permissions on a local resource or on a remote resource that your ASP.NET application is trying to access.
Tip
You can contact your developer to find out how to see the actual error message. It's possible that your developer may be logging it to a file or getting e-mail notifications. Always remember to make a backup of any file that you are going to change. With a backup available, you can always roll back any changes.
Issue occurs because of missing permissions on a local resource that the ASP.NET application tries to access
If you are unable to get a clear description of the problem because of a custom error message, run FileMon and reproduce the problem. Stop and save the capture as FileMon.xls and open the file in Microsoft Excel. On the Data menu, click Filter, and then click AutoFilter to use the filtering capabilities of Excel. Now select the drop-down list in column F and look for 'ACCESS DENIED' errors.
A sample FileMon output is shown below.
As you can see from the filtered results, we have narrowed down the cause of the problem. FileMon shows that the NT AUTHORITYNETWORK SERVICE account is missing NTFS permissions on the C:WinntMicrosoft.netFrameworkv1.1.4322Temporary ASP.NET Files folder. This should be straight forward to fix.
Tip
A good step would be to change the ASP.NET process account to an Admin account to see if it fixes the problem. In IIS 6.0 and later versions you would change the IIS AppPool identity to 'Local System' to see if the application works.
Note
This should not be used as a solution, but only as a troubleshooting step.
Most people would tend to reinstall the Microsoft .NET Framework or even go to the extent of reinstalling the operating system. This is not a recommended troubleshooting step and does not guarantee that the issue will not reoccur. I will provide one such example. Intermittent issues are often hard to isolate and troubleshoot. In this scenario the customer's application would work fine for a few hours, and then all of a sudden it would fail with the error below. The customer had already tried reinstalling the .NET Framework as well as the operating system. This seemed to fix the problem for a few days, but then it reappeared.
Running FileMon did not show any ACCESS DENIED errors. All the necessary permissions for the ASPNET account were in place. The only way to recover from the problem is to reboot the box. Even an IIS reset would not help. You are thinking 'Ah, Microsoft Software always needs a reboot to recover?' Well, you are wrong!
The key here is to look closely at the error message. The error clearly says 'cannot open a file for writing,' and not the usual ACCESS DENIED error, so I am thinking that it's some other process that is holding a lock on a file or folder and not allowing ASP.NET to write to it. It makes sense that a reboot was killing the other process and the ASP.NET application starts working again until the rogue process locks the file again. The logical thing to do would be to turn off all antivirus programs, third-party spyware, or any other file monitoring software that runs on the server. I do not want to point out any specific third-party software. But, in general, antivirus software is known to cause much grief for IIS and ASP.NET applications. Another known issue caused by antivirus software is session loss due to AppDomain recycles when the Bin folder or the .config files are touched.
Tip
The easiest way to turn off third-party services is to:
- Click Start, click Run, and then type msconfig.
- Select Services and check Hide All Microsoft Services.
- Click Disable All to stop the third-party services.
- Click Start, click Run, and then type iisreset to reload the CLR into the worker process.
Monitor your application to see if the issue reoccurs. If you run multiple antivirus programs, use the trial-and-error method to determine which particular program is causing the issue.
Note
If the same error is reproducible 100 percent of the time, your antivirus software may not be the cause. There can be other causes for this error. Try creating a simple ASP.NET test application to isolate whether the same error occurs for a Test.aspx page. If it does, then verify that the required Access Control Lists (ACLs) are all in place for ASP.NET.
See ASP.NET Required Access Control Lists (ACLs).
Tip
The %SystemRoot%Assembly folder is the global assembly cache. You cannot directly use Windows Explorer to edit ACLs for this folder.
Instead, use a command prompt and run the following command:
cacls %windir%assembly /e /t /p domainuseraccount:r
Alternatively, prior to using Windows Explorer, unregister Shfusion.dll with the following command to give permissions via the GUI:
C:WINDOWSMicrosoft.NETFrameworkVersionNumber>regsvr32-u shfusion.dll
After setting permissions with Windows Explorer, re-register Shfusion.dll with the following command:
C:WINDOWSMicrosoft.NETFrameworkVersionNumber>regsvr32 shfusion.dll
Issue occurs because of missing permissions on a remote resource that the ASP.NET application is trying to access
When your ASP.NET application is accessing a remote resource like Microsoft SQL Server or a Universal Naming Convention (UNC) share, there are many things that can go wrong. Also, many things may be incorrectly set up on the remote resource. You'll need to troubleshoot those issues in order to get the resource working.
Your first step would be to see if you can connect to the remote server through Windows Explorer.
On the remote server, create a folder called Test. On the Sharing and Security tabs of the Test folder, add your domain/account, and also the process account that is used by your ASP.NET application, and give them both Full Control.
On the IIS server, log in with your domain/account, click Start, click Run, and then type the UNC share path of the remote server:
RemoteServerName*Test.If you are unable to get to this folder, then contact your Network Administrator to fix this issue. Only then can your ASP.NET application access the share.
Create a file called CreateUNCFile.aspx with the code below and save the file in your application directory.
Make sure that you modify <RemoteServerName> in the following line of code
So that it reflects the name of your remote server.
Open Windows Internet Explorer and browse to
http://**IISServerName**/**AppName**/CreateUNCFile.aspxfrom a client computer other than the IIS server.If the Test.txt file creates successfully, then your ASP.NET application can authenticate to the remote resource.
If file creation fails from an Internet Explorer client browser but works if you browse to the same page from the IIS server itself, then it's likely that you are running into a 'Double Hop' scenario. If you are using custom built Web Parts to access remote resources that require user authentication and authorization, you will probably run into the 'Double Hop' problem. In order to access your remote resource, you may need to supply the end user's credentials to the resource so that the output from the resource is limited to the data that the end user has permission to access.
The above steps assume that you have NTLM Authentication turned on in IIS. Basic Authentication does not use Kerberos.
For more information, see Troubleshoot Kerberos failures in Internet Explorer.
For more information on IIS authentication methods, see Visual Studio 2003 Retired Technical documentation.
Tip
If you can connect to the remote UNC share but you can not connect to the remote server that is running SQL Server from the ASP.NET application, then you might have to check or set the Service Principal Names (SPNs) for SQL Server. Try enabling only Basic Authentication for your application in IIS and see if you are able to connect to the remote server that is running SQL Server.
There are numerous other causes for the 'Server Application Unavailable' error message. The event log is your best bet to get more details on the cause of your issue.
IIS-related errors
The IIS logs are useful in cases of IIS authentication-related errors.
What you need to look for is the status and sub status codes for this particular error.
We see a 401 with the substatus 3, which indicates 'Unauthorized due to ACL on resource.'
This indicates missing NTFS permissions on a file or folder. This error may occur even if the permissions are correct for the file that you are trying to access, but the default permissions and user rights may be missing on other SYSTEM and IIS folders. For example, you may see this error if the IUSR_ComputerName account does not have access to the C:WinntSystem32Inetsrv directory.
Tip
Click Start, click Run, and then type logfiles to open the folder that contains the IIS logs. Alternatively, on the properties page for your Website in IIS, click the WebSiteName tab, and under Active log format, click Properties to see the Log file directory and name.
The other thing of interest here is the status code 5. You can use the net helpmsg command to get more info on this status code:
C:Documents and SettingsUser> net helpmsg 5
Access is denied.
Let's try another common status code, code 50:
C:Documents and SettingsUser> net helpmsg 50
The request is not supported.
Tip
Whenever you get another generic infamous '500 Internal Server Error' message, then it's a good idea to disable friendly HTTP error messages, so that you receive a detailed description of the error. Don't forget to look in the event viewer as it may also contain more information.
The idea is to use all the logged information available to get maximum details on the problem at hand.
Resources
For more information, see:
-->This article helps fix an issue where you can't start a Microsoft Store App if the default registry or file permissions is modified.
Applies to: Windows 10 - all editions
Original KB number: 2798317
Note
This article is intended for IT professionals. For home users who encounter Microsoft Store App issues, go to Fix problems with apps from Microsoft Store.
Issue 1
When you select a Microsoft Store App, the App begins to start, and then Windows just returns to the start screen. No on-screen error is displayed.
Microsoft-Windows-Immersive-Shell event 5961 is logged under the Applications and Services LogsMicrosoftWindowsAppsMicrosoft-Windows-TWinUI/Operational event log path:
Note
The app portion of the example event, <app name>, will change depending on the application that fails to start.
Possible values for <app name> include but aren't limited to:
microsoft.windowscommunicationsapps_8wekyb3d8bbwe!Microsoft.WindowsLive.Chat
Prefixes for other built-in Microsoft Store Apps include:
Microsoft.BingFinance_8wekyb3d8bbwe!<app identifier>
Microsoft.BingMaps_8wekyb3d8bbwe!<app identifier>
Microsoft.BingNews_8wekyb3d8bbwe!<app identifier>
Microsoft.BingSports_8wekyb3d8bbwe!<app identifier>
Microsoft.BingTravel_8wekyb3d8bbwe!<app identifier>
Microsoft.BingWeather_8wekyb3d8bbwe!<app identifier>
Microsoft.Bing_8wekyb3d8bbwe!<app identifier>
Microsoft.Camera_8wekyb3d8bbwe!<app identifier>
Microsoft.Media.PlayReadyClient_8wekyb3d8bbwe!<app identifier>
microsoft.microsoftskydrive_8wekyb3d8bbwe!<app identifier>
Microsoft.Reader_8wekyb3d8bbwe!<app identifier>
Microsoft.VCLibs.110.00_8wekyb3d8bbwe!<app identifier>
microsoft.windows.authhost.a_8wekyb3d8bbwe!<app identifier>
microsoft.windowscommunicationsapps_8wekyb3d8bbwe!<app identifier>
microsoft.windowsphotos_8wekyb3d8bbwe!<app identifier>
Microsoft.WinJS.1.0.RC_8wekyb3d8bbwe!<app identifier>
Microsoft.WinJS.1.0_8wekyb3d8bbwe!<app identifier>
Microsoft.XboxLIVEGames_8wekyb3d8bbwe!<app identifier>
Microsoft.ZuneMusic_8wekyb3d8bbwe!<app identifier>
Microsoft.ZuneVideo_8wekyb3d8bbwe!<app identifier>
Issue 2
You can't start a Microsoft Store App, open Start screen, and use Search in Windows. Additionally, you receive the following event log in Application logs:
If you use Process Monitor to track the Apps' executable or related files, you may see access denied is logged. It points to the missing permissions for the current logon user. It includes:
Registry hives and its subkeys:
- HKEY_CLASSES_ROOT
- HKEY_LOCAL_MACHINEDrivers
- HKEY_LOCAL_MACHINEHARDWARE
- HKEY_LOCAL_MACHINESAM
- HKEY_LOCAL_MACHINESOFTWARE
- HKEY_LOCAL_MACHINESYSTEM
- HKEY_USERS
For file subsystem:
- Program Files - Read, Read and Execute, and List folder Contents
- Windows - Read, Read and Execute, and List folder Contents
- Users<userName>AppDataLocalMicrosoftWindowsWER - Special Permissions (List folder/read data, and Create Folders/Append Data)
Cause for issue 1
Registry and or file system permissions may have been changed from their defaults.
The All Application Packages group is a well-known group with a predefined SID. The group must have specific access to certain locations of the registry and file system for Microsoft Store Apps to function properly.
Cause for issue 2
This issue occurs because the read permission is missing from any or all the keys. In this case, 0xc000027b is logged. This error without exception is missing permission for ALL APPLICATION PACKAGES at registry location or file subsystem locations.
Registry and file system permission must be reverted to a state that will allow Microsoft Store App to function
Note
Only change the permission of the registry keys that are known to cause the access denied error. Incorrectly changing registry keys' permission might cause serious problems or unintentionally weaken security settings.
Extensive permission changes that are propagated throughout the registry and file system cannot be undone. Microsoft will provide commercially reasonable efforts in line with your support contract. However, you cannot currently roll back these changes. We can guarantee only that you can return to the recommended out-of-the-box settings by reformatting the hard disk drive and by reinstalling the operating system.
If you use Group Policy to manage permissions, or if you're unsure whether Group Policy is used to manage permissions, follow these steps:
- Unjoin the computer from the domain or put the computer in a test OU with block policy inheritance enabled. This action prevents the domain-based Group Policy from reapplying the permission changes and breaking the modern applications again after you've fixed them.
- Add permissions where they're required per the following details.
- Edit the Group Policy that manages to permissions so that it no longer breaks modern application.
Registry and File System permission must be reverted back to a state that will allow Microsoft Store App to function. Follow this method to resolve the issue:
- Determine if file system permissions have been changed. If not, see the More information section below.
- If so, how were they changed? Manually or with Group Policy?
- Determine if registry permissions have been changed If not, see the More information section below.
- If so, how were they changed? Manually or with Group Policy?
- Verify secpol and GPPs specifically.
Determine if file system permissions have been changed
Check the folders listed below. Determine if the All Application Packages group has the access indicated. Most but not all sub directories of Windows, Program Files, and WER also grant permissions to the All Application Packages group.
- Program Files - Read, Read and Execute, and List folder Contents
- Windows - Read, Read and Execute, and List folder Contents
- Users<userName>AppDataLocalMicrosoftWindowsWER - Special Permissions (List folder/read data, and Create Folders/Append Data)
Determine if registry permissions have changed
Check the registry keys listed below. Make sure the All Applications Packages group has the Read permissions to the following registry paths:
Desk Rt Acl Denied Claim
- HKEY_CLASSES_ROOT
- HKEY_LOCAL_MACHINEDrivers
- HKEY_LOCAL_MACHINEHARDWARE
- HKEY_LOCAL_MACHINESAM
- HKEY_LOCAL_MACHINESOFTWARE
- HKEY_LOCAL_MACHINESYSTEM
- HKEY_USERS
Most but not all of the subkeys of the registry keys listed above will grant the All Application Packages group read access.
Determine if Group Policy is being used to manage permissions
Sign in to a PC as a user experiencing the problem.
Open an administrative command prompt then run the following command:
Open the file gpreport.html and expand the following path:
Computer Settings > PoliciesWindows SettingsSecurity Settings. Look for File System and Registry. If these exist, then GP is assigning permission. You must edit the GP to include the necessary permissions for the All Application Packages group.
Desk Rt Acl Denied Symptoms
Steps to fix the problem
Depending on how the file system permissions were changed will determine how to recover from the problem. The most common ways permissions are changed manually and by Group Policy.
Important
Make sure that you test your resolution in a lab before widely deploying. Always backup any important data before changing registry and file system permissions.
Fix file system permissions that's changed manually
- Open File Explorer.
- Browse to c:Program Files.
- Right click and select properties.
- Select the Security tab.
- Select the Advanced button.
- Select the Change permissions button.
- Select the Add button.
- Select the Select a principal link.
- Select the locations button and select the local computer.
- Add the All Applications Packages group name and select ok.
- Make sure that Type = allow and Applies to = This folder, subfolder, and files.
- Check Read & Execute, List folder contents, and Read.
- Check the Replace all child object permissions with inheritable permission entries from this object checkbox.
- Select Apply and OK.
- Repeat for c:Windows.
- Repeat for c:Users but grant the All Application Packages group Full Control.
- Select Apply and OK.
Fix file system permissions that's changed by Group Policy
Have a Group Policy administrator do the following steps:
- Open Group Policy Administrative Console.
- Locate the GPO identified in the step Determine if Group Policy is being used to manage permissions.
- Right-click and select edit.
- Go to the location Computer
ConfigurationPolicyWindows SettingsSecurity SettingsFile System. - If there's an entry for the paths already created, you can edit it. If no entry exists, create a new entry for each path.
- To create a new entry, right-click file system and select add file.
- Browse to the path c:Program Files, select OK.
- Select the Add button.
- Select the locations button and select the local machine name.
- Add the All Application Packages group and grant them the Read, Read and Execute, and List folder Contents permissions.
- Select Apply and OK.
- Select the Replace existing permissions on all subfolders and files with inheritable permissions option.
- Repeat for C:Windows.
- Repeat for C:Users, however, grant the All Application Packages group Full Control.
You'll need to wait for the Group policy change to replicate to all Domain Controllers and for all clients to update their Group Policy settings.
Note
Processing the File System changes will incur some logon delay the first time this policy is processed. Subsequent logons will not be impacted unless changes are made to the policy. As an alternative you can use a script that is called post logon by the user is run as a scheduled task.
Fix registry permissions that's changed manually
- Open regedit.exe.
- Right click on HKEY_Users and select properties.
- Make sure that All Application Packages has Read.
- Repeat for HKEY_CLASSES_ROOT.
- Expand HKEY_LOCAL_MACHINE. Check the subkeys HARDWARE, SAM, SOFTWARE, SYSTEM. Make sure that All Application Packages has the Read permission.
Fix Registry Permissions that's changed by Group Policy
Have a Group Policy administrator do the following steps:
- Open Group Policy Administrative Console.
- Locate the GPO identified in the step Determine if Group Policy is being used to manage permissions.
- Right-click and select edit.
- Go to the location Computer
ConfigurationPolicyWindows SettingsSecurity SettingsRegistry. - Right Click and select Add Key.
- Select CLASSES_ROOT.
- Select the Add button.
- Select the locations button and select the local machine name.
- Add the All Application Packages group and grant them Read.
- Repeat for Users.
- Repeat for MACHINEHARDWARE, MACHINESAM, MACHINESOFTWARE, and MACHINESYSTEM.
More information
For more information, see Microsoft Store Apps Fail to Start if the User Profiles or the ProgramData directory are Moved from their Default Location.
File system and registry access control list modifications
Windows XP and later versions of Windows have tightened permissions throughout the system. So extensive changes to default permissions shouldn't be necessary.
Extra discretionary access control list (DACL) changes may invalidate all or most of the application compatibility testing done by Microsoft. Frequently, changes such as these haven't undergone the thorough testing that Microsoft has done on other settings. Support cases and field experience have shown that DACL edits change the fundamental behavior of the operating system, frequently in unintended ways. These changes affect application compatibility and stability and reduce functionality, about both performance and capability.
Because of these changes, we don't recommend you modify file system DACLs on files that are included with the operating system on production systems. We recommend you evaluate any other ACL changes against a known threat to understand any potential advantages that the changes may lend to a specific configuration. For these reasons, our guides make only minimal DACL changes and only to Windows 2000. For Windows 2000, several minor changes are required. These changes are described in the Windows 2000 Security Hardening Guide.
Extensive permission changes propagated throughout the registry and file system can't be undone. New folders, such as user profile folders that weren't present at the original installation of the operating system, may be affected. So you can't roll back the original DACLs if you:
- remove a Group Policy setting that performs DACL changes
- apply the system defaults
Changes to the DACL in the %SystemDrive% folder may cause the following scenarios:
- The Recycle Bin no longer functions as designed, and files cannot be recovered.
- A reduction of security that lets a non-administrator view the contents of the administrator's Recycle Bin.
- The failure of user profiles to function as expected.
- A reduction of security that provides interactive users with read access to some or to all user profiles on the system.
- Performance problems when many DACL edits are loaded into a Group Policy object that includes long logon times or repeated restarts of the target system.
- Performance problems, including system slowdowns, every 16 hours or so as Group Policy settings are reapplied.
- Application compatibility problems or application crashes.
To help you remove the worst results of such file and registry permissions, Microsoft will provide commercially reasonable efforts in line with your support contract. However, you can't currently roll back these changes. We can guarantee only that you can return to the recommended out-of-the-box settings by reformatting the hard disk drive and by reinstalling the operating system.
For example, modifications to registry DACLs affect large parts of the registry hives and may cause systems to no longer function as expected. Modifying the DACLs on single registry keys poses less of a problem to many systems. We recommend you carefully consider and test these changes before you implement them. And we can guarantee only that you can return to the recommended out-of-the-box settings if you reformat and reinstall the operating system.