Why does SHGetSpecialFolderPath take such a long time before returning a network error?

Raymond Chen

A customer reported that their program was failing to start up because the call to SHGet­Special­Folder­Path(CSIDL_PERSONAL) was taking a long time and then eventually returning with ERROR_BAD_NETPATH. The account that was experiencing this problem had a redirected network profile, “but even if he’s redirecting, why would we get the bad net path error? Does calling SHGet­Folder­Path actually touch the folder/network? If so, we should probably stop calling this function on the UI thread since network problems could cause our program to hang.” The SHGet­Folder­Path function will access the network if you pass the CSIDL_FLAG_CREATE flag, which says “Check if the folder is there, and if not, create it.” The customer had been passing the flag. “We’ll remove it. As if our program is going to dictate the creation of the user profile directory.” The CSIDL_FLAG_CREATE flag has been implicated in some other unwanted behavior. For example, if you pass the CSIDL_FLAG_CREATE flag when asking for CSIDL_MYPICTURES, this will create a My Pictures directory if there wasn’t one before. Generally speaking, you shouldn’t be creating these directories as side-effects of other actions. Corporate administrators may suppress creation of folders like Pictures and Videos, but that doesn’t do much good if your program casually creates them as part of its startup.

Note that SHGet­Special­Folder­Path and CSIDL values have been superseded by SHGet­Known­Folder­Path and KNOWN­FOLDER­ID. The flag corresponding to CSIDL_FLAG_CREATE is KF_FLAG_CREATE. If you want to make things even faster, consider passing the KF_FLAG_DONT_VERIFY flag (formerly known as CSIDL_FLAG_DONT_VERIFY).

Raymond Chen

Follow