Floele

This was my lazy quick and dirty attempt: const HRESULT hr = TShell::SHGetKnownFolderPath(FOLDERID_RoamingAppData, 0, NULL, &path); I assume this still works because it only accesses one specific folder and doesn't try to verify all of them. It would probably hang as well if %appdata% was broken but in that case we're screwed anyway.

SHGetKnownFolderPath seems to work fine!

Sure: > ntdll.dll!_NtWaitForSingleObject@12() KernelBase.dll!WaitForSingleObjectEx() KernelBase.dll!_WaitForSingleObject@8() p9np.dll!_NPEnumResource@16() mpr.dll!MprEnumConnect() mpr.dll!WNetEnumResourceW() shell32.dll!CMountPoint::_InitNetDrivesHelper(unsigned long) shell32.dll!CMountPoint::_InitNetDrives(void) shell32.dll!CMountPoint::_IsNetDriveLazyLoadNetDLLs(int) shell32.dll!CMountPoint::_GetMountPointForDriveLetter(int,class CMountPoint * *) shell32.dll!CMountPoint::GetMountPoint(int,class...

OK I can confirm that aclock suffers from the same issue in Dynamic Debug/Release but works fine in Static Debug/Release (6.44). In 6.36 Dynamic Debug/Release works fine.

As for reproduction, the following C# app is sufficient, resulting in an app hang. So basically any LoadLibrary call of either owl-6.44-v1930-x86-5t.dll or owl-6.44-v1930-x86-5dt.dll. With this minimal test case, this also applies to owl-7.0-v1930-x86-5t.dll. internal static class Program { [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)] private static extern IntPtr LoadLibrary(string lpFileName); const string DLL_NAME = "owl-6.44-v1930-x86-5t.dll"; [STAThread] static...

Actually, 6.44 isn't the latest version of OWLNex Sorry maybe I shouldn't have phrased it like that. Please ignore. I don't dare to upgrade to v7 yet. Do you see same behaviour on Windows Vista to 11? I am currently seeing it on Win11, but we can check if other versions are affected too. We're only using 32 bit (so far). The stack is from my local debug version but unfortunately we've seen this on customer systems first (release version). Which app? Can it be reproduced by one of our examples? I...

Hi, it looks like we might have another issue with the latest version of OWL that wasn't there before. If you change any of the common folders (like documents, pictures, videos - the folders shown in the left area of Windows Explorer) to a non existent drive, our app will hang on startup: ntdll.dll!_NtWaitForSingleObject@12() Unbekannt KernelBase.dll!WaitForSingleObjectEx() Unbekannt KernelBase.dll!_WaitForSingleObject@8() Unbekannt p9np.dll!_NPEnumResource@16() Unbekannt mpr.dll!MprEnumConnect()...

Indeed this works fine, thanks for your support and the workaround!