Fails to find SHGetSpecialFolderPathA in shell32.dll on Windows NT 4




13 years ago
13 years ago


(Reporter: Matthew Hambley, Assigned: Blake Ross)


Firefox Tracking Flags

(Not tracked)




13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2) Gecko/20040707 Firefox/0.8.0+
Build Identifier:

The browser fails to start with the error "The procedure entry point
SHGetSpecialFolderPathA could not be located in the dynamic link library
shell32.dll"  This problem has existed since I started looking at the branch
builds on the 8th.

I have upgraded my Windows installation as far as I can and shell32.dll reports
its version as 4.00 from the file explorer.  According to MS documentation this
error can accur if an insufficiently recent version of IE is installed and
recomends at last version 4.  I have version 6 installed.

Reproducible: Always
Steps to Reproduce:
1. Launch Firefox

Actual Results:  
An error box appears containing "The procedure entry point
SHGetSpecialFolderPathA could not be located in the dynamic link library
shell32.dll".  The firefox process then dies.

Expected Results:  
Started running.

Comment 1

13 years ago
I can confirm this bug on Win NT4 with IE6 (except the message is in french).
This bug seems to be related to bug 54198 (which has a patch attached but no
review). This bug only happens on branch builds, not 0.9.2.

Comment 2

13 years ago
SHGetSpecialFolderPathA only appears twice in the source (Aviary branch), both
times in the same file /xpcom/io/SpecialSystemDirectory.cpp, line 113 and 119,
and once of those times in a comment.

However the modifications to that part of that file come from 2003, so I can't
see how it could be the culprit.

Comment 3

13 years ago
I've narrowed it down to:
* Firefox build 2004-06-22-10-0.9 starts correctly
* Firefox build 2004-06-23-10-0.9 fails with SHGetSpecialFolderPathA 

Comment 4

13 years ago
(sorry for the bug spam)

The trunk builds from 2004-07-18 work perfectly, however the branch builds (0.9)
do not.

Comment 5

13 years ago

Comment 6

13 years ago
it looks like that we need a working IE installation to run

Comment 7

13 years ago
from one of the Google links

Apparently SHGetSpecialFolderPath doesn't work without the shell update
installed on NT4. Therefore, substituting this function will help:

BOOL UtilGetSpecialFolderPath (
char *path, // Path buffer
int folder) // Special folder ID
ITEMIDLIST *pidl; // Shell Item ID List ptr
IMalloc *imalloc; // Shell IMalloc interface ptr
BOOL result; // Return value

if (SHGetSpecialFolderLocation (NULL, folder, &pidl) != NOERROR)
return FALSE;

result = SHGetPathFromIDList (pidl, path);

if (SHGetMalloc (&imalloc) == NOERROR) {
imalloc->lpVtbl->Free (imalloc, pidl);
imalloc->lpVtbl->Release (imalloc);

return result;

Thanks to Roger Hunen who posted this on

Comment 8

13 years ago
This has been caused by the patch to bug 246616.
calls directly SHGetSpecialFolderLocation (which is mapped by the compiler to

The code should be modified in a way similar to SpecialSystemDirectory.cpp#113,
maybe encapsulate both calls to SHGetSpecialFolderLocation (and other functions
that may sometimes be missing) inside a function that will do the right thing.
Depends on: 246616
Ever confirmed: true

Comment 9

13 years ago
In fact, the problem is already taken care of within bug 246616 with a patch (I
should have read all the comments), so I'll mark duplicate.

*** This bug has been marked as a duplicate of 246616 ***
Last Resolved: 13 years ago
No longer depends on: 246616
Resolution: --- → DUPLICATE

Comment 10

13 years ago
This bug is marked as a duplicate of 246616, and 246616 has been marked as
fixed. The patch still has to make it into the branch, so should this really be
marked as duplicate, or should a new bug be filed ?

The patch is
You need to log in before you can comment on or make changes to this bug.