Join Log in
Score:0
FLDelphi avatar Server

Slow loading times getting .mun file from a network share

cr flag
FLDelphi

I have a client with a 2019 Standard Windows Server and a Windows 10 Pro desktop. Server has a network share \server\programshare.

Most times when opening a program in the share from the client, we experience severely degraded load times.

I used Process Monitor to analyze when it's slow vs when it's fast and noticed the culprit may be when Windows attempts to access a .mun file from \server\SystemResources and it receives a result OF BAD NETWORK NAME.

Here's an excerpt from a slow log (15 seconds of loading on a gb connection):

"1:34:34.5658167 PM","TestApplication.exe","9108","CreateFile","C:\Windows\SysWOW64\wer.dll","SUCCESS","Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened","0.0011367","1:34:34.5669534 PM","00:00:15.6818193","n/a"
"1:34:34.5724983 PM","TestApplication.exe","9108","CreateFile","C:\Users\training\AppData\Local\Temp\120A378B-65D0-43E3-82B5-206674D078DB.tmp","SUCCESS","Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created","0.0001357","1:34:34.5726340 PM","00:00:15.6885009","n/a"
"1:34:34.5768623 PM","TestApplication.exe","9108","FileSystemControl","\\server\IPC$","FS DRIVER REQUIRED","Control: FSCTL_DFS_GET_REFERRALS","0.0005762","1:34:34.5774385 PM","00:00:15.6928649","n/a"
"1:34:49.1749458 PM","TestApplication.exe","9108","CreateFile","\\server\SystemResources\TestApplication.exe.mun","BAD NETWORK NAME","Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a","0.0071285","1:34:49.1820743 PM","00:00:30.2909484","n/a"
"1:34:49.1760410 PM","TestApplication.exe","9108","FileSystemControl","\\server\IPC$","FS DRIVER REQUIRED","Control: FSCTL_DFS_GET_REFERRALS","0.0005707","1:34:49.1766117 PM","00:00:30.2920436","n/a"
"1:34:49.1905672 PM","TestApplication.exe","9108","CreateFile","\\server\programshare\","SUCCESS","Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened","0.0005615","1:34:49.1911287 PM","00:00:30.3065698","n/a"

There's not much to learn about .mun files on the internet. Apparently they are some compressed info that might contain the icon. I did notice that during slow loads even Process Monitor wasn't displaying the icon in it's stream. Once the big load finished, Process Monitor displayed the icon and the program could finally get started.

My hunch is this is network related, specifically because sometimes it does load just fine. My question is if there's a way to change how the .mun file is loaded. We don't have a lot of control over the network at large.

Here's someone from 2021 with the same issue and no resolution: https://learn.microsoft.com/en-us/answers/questions/285173/windows-10-try-to-load-non-existing-mun-files

96
0 + 3
djdomi avatar
za flag
djdomi
I would suggest that you make a alias and test if it's still an issue. moreover check the app source for SystemResources maybe it's a hard-coded path
0
Reply
FLDelphi avatar
cr flag
FLDelphi
No luck with the alias. What we did discover is that running the application through a mapped drive (as opposed to a UNC path) prevented Windows from trying to load the .mun file.
0
Reply
djdomi avatar
za flag
djdomi
i think the app needs to be recompiled, i found a hint that it tries to use files that are not exist on specific paths: https://learn.microsoft.com/en-us/answers/questions/285173/windows-10-try-to-load-non-existing-mun-files
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.