Click here to Skip to main content
15,886,518 members
Please Sign up or sign in to vote.
2.33/5 (2 votes)
See more:
I was tring to use SymEnumSourceFiles to get the file name within the debugging module.But the file name as a parameter in the callback function seems incomplete. e.g. A file named"c:\\program files\\test\\test.cpp" only showed "c:\\program fi" in the FileName part of the PSOURCEFILE type parameter, and that's very wired.
Here is my code:
C++
    struct foo
{
    static BOOL CALLBACK run( PSOURCEFILE pSourceFile, PVOID UserContext)
    {
        static TCHAR szFileName[MAX_PATH] = _T("");
        if (_tcscmp(szFileName, pSourceFile->FileName))
        {
            _tcscpy(szFileName, pSourceFile->FileName);
        }
        return TRUE;
    }
};

    HANDLE hCurrentProcess = GetCurrentProcess();
SymInitialize(hCurrentProcess, NULL, FALSE);
DWORD64 BaseOfDll = SymLoadModule64(hCurrentProcess,
                                        NULL,
                                       (LPCSTR)_bstr_t(lpszFile),
                                        NULL,0,0);
if(!SymEnumSourceFiles(hCurrentProcess, BaseOfDll, NULL, foo::run, (PVOID)pCallBack))
{
    ATLTRACE(_T(__FUNCTION__) _T(" error:0x%x\n"), GetLastError());
}
SymUnloadModule64(hCurrentProcess, BaseOfDll);
SymCleanup(hCurrentProcess);


Can anyone tell me where I go wrong please?
PS. When I simply replace SymEnumSourceFiles with SymEnumLines and change the callback function, the file name I got is correct.
Posted
Comments
Sergey Alexandrovich Kryukov 23-Jul-13 0:27am    
You did not show where pCallback is initialized...
Function run is incorrect: not all paths return a value (you only return TRUE, never anything else), szFileName is empty in all cases; makes no sense.
—SA
ericchan1336 23-Jul-13 1:32am    
The value of pCallback is not the point. What I posted here is juet s demo, and the point is why the pSourceFile->FileName is incomplete. No matter what pCallback is, the value of pSourceFile->FileName will not be changed, we can agree with that, right?
Sergey Alexandrovich Kryukov 23-Jul-13 1:36am    
A point or not, how can we make sure it's right? FileName will not be changed? Hm... the fact is, it is changed, but did you check up its value before this call? Anyway, incompleteness of the code sample creates many doubts.
—SA
ericchan1336 23-Jul-13 3:40am    
It's a callback function, the system set the value of pSourceFile, and as you can see in the demo, I didn't change it.
Sergey Alexandrovich Kryukov 23-Jul-13 10:16am    
Nevertheless, it does not look correct. How about the answer about Microsoft bug? Will you confirm that the path name is cut exactly by the factor of 2?
—SA

1 solution

This definitely looks like a microsoft bug. If you run this in ASCII mode then the filenames returned are correct. If you run it in Unicode mode then all returned names are (approx) half the correct size. It looks like the code is miscalculating the filename length by dividing by 2 in a Unicode build. I would suggest you report it to MS.
 
Share this answer
 
Comments
ericchan1336 23-Jul-13 21:01pm    
Thanks Richard, I tried what you did and the result is the same as you said.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900