从你提供的Procmon日志里的IS DIRECTORY标记，我找到了几个最可能的原因，咱们一个个来排查：

1. 存在同名的隐藏目录（最优先排查） #

你提到确认目标文件不存在，但有没有检查过是否存在一个名叫Competencies.csv的文件夹？系统绝对不允许在同一路径下创建同名的文件和目录，哪怕这个目录是隐藏状态的，你在资源管理器里可能看不到。

可以通过命令提示符快速验证：

dir D:\inetpub\ftproot /a:d

这个命令会列出该目录下所有类型的文件夹（包括隐藏和系统级别的）。如果发现Competencies.csv目录，删除它之后再尝试写入文件，问题大概率能解决。

2. Windows Defender或第三方安全软件拦截了.csv写入 #

Windows的**受控文件夹访问（Controlled Folder Access）**功能会默认保护inetpub这类系统目录，阻止未经授权的程序修改特定类型的文件。.csv可能被识别为“潜在风险”文件（比如可能包含恶意数据格式），而.txt则不在拦截列表里。

你可以这么测试：

• 暂时关闭受控文件夹访问：打开「设置>更新和安全>Windows安全中心>病毒和威胁防护>病毒和威胁防护设置>管理设置>受控文件夹访问」，选择关闭，再试写入.csv。
• 如果关闭后正常，就把w3wp.exe（IIS工作进程）添加到受控文件夹访问的允许列表里，避免后续再次拦截。
• 检查第三方杀毒软件/防火墙的规则，看是否有针对.csv文件写入的拦截策略。

3. 应用程序池身份权限遗漏（容易忽略的点） #

虽然你修改了IIS基本设置的连接账户，但应用程序池的运行身份才是决定文件系统权限的核心。如果你的程序所在的应用程序池使用的是默认的ApplicationPoolIdentity，哪怕你给Everyone开了完全控制权限，这个专用身份可能还是没有被授予目录的写入权限。

解决步骤：

• 打开IIS管理器，找到你的程序对应的应用程序池，进入「高级设置」查看“标识”字段。
• 给这个标识（格式通常是IIS AppPool\你的池名称）手动授予D:\inetpub\ftproot目录的完全控制权限（不要只依赖Everyone，部分安全机制会优先识别专用身份的权限）。

补充验证小技巧 #

你可以先手动在ftproot目录下创建一个Competencies.csv文件：

• 如果手动都创建失败，那肯定是系统安全机制或同名目录的问题；
• 如果手动能创建，那就是程序运行的进程身份（应用程序池身份）没有足够权限。

内容的提问来源于stack exchange，提问作者Velocedge