DOpus Freezes After HDD Spins Down For A While

There seems to be an issue with DOpus when you try to use it after a drive spins down with a folder from that drive open up and in Thumbnails Mode.

Basically copy a lot of images or videos into a folder that's on an external drive that spins down when it's inactive after a certain time. Switch over to Thumbnails Mode and then just minimize that DOpus window and leave it there for at least 30 minutes to make sure the drive spins down. At least during my test, I did not touch DOpus at all for the duration of that time (no new listers or anything at all). After at least 30 minutes, you can restore the DOpus window and try to browse through the menu. You could also try open up a new lister through Right Click Desktop -> New Lister. DOpus would then freeze.

I have emailed you a dopus.exe.dmp file that I made using Task Manager.

Do you mean it stays frozen, or just that it takes a few seconds as it waits for the drive to spin up again (which is normal, if the drive has spun down and then is accessed by anything)?

It stayed completely frozen. Doesn't seem to be an issue though if I leave it open in Details Mode though. It is only an issue when I left it open in Thumbnails mode.

It looks like the plugin you are writing has crashed, and possibly crashed in a bad place which has caused every other thread in the process to freeze (the DLL Loader Lock is held by something).

(As an aside, writing a plugin using .Net is uncharted territory.)

Oh yeah. That is the problem! Thanks!

What's odd though is the plugin is bare bones at the moment and only has a few lines of code that uses the API from WebP's libary to identify the file (DVP_IdentifyFileBytesW) and doesn't do anything else. Also, .NET? I thought Visual C++ does not use .NET? I'm only using standard C++ libraries at the moment. Seems like I may have started the project as C++/CLI. I will have to take a look at it later.

// Identify the viewer plugin to DOpus
BOOL DVP_Identify(LPVIEWERPLUGININFO lpVPInfo)
{
	// Plugin flags; we can handle streams, and only use filename extensions for identification for slow and non-random seeking media
	lpVPInfo->dwFlags = DVPFIF_CanHandleBytes |
		DVPFIF_CanHandleStreams |
		DVPFIF_ExtensionsOnlyIfSlow |
		DVPFIF_ExtensionsOnlyIfNoRndSeek |
		DVPFIF_ExtensionsOnlyForThumbnails |
		DVPFIF_InitialDisable;

	// Version number (1.0.0.0)
	lpVPInfo->dwVersionHigh = MAKELONG(0, 1); // Use MAKELONG instead of MAKELPARAM to avoid error assigning to DWORD under 64-bit.
	lpVPInfo->dwVersionLow = MAKELONG(0, 0);

	// Preferred filename extension is .webp
	lpVPInfo->lpszHandleExts = _T(".webp");

	// Plugin information
	lpVPInfo->lpszName = _T("WebP");
	lpVPInfo->lpszDescription = _T("WebP Viewer Plugin");
	lpVPInfo->lpszCopyright = _T("(c) Copyright 2017 Enternal");
	lpVPInfo->lpszURL = _T("http://www.gpsoft.com.au/");

	// Major type of file we handle is images
	lpVPInfo->uiMajorFileType = DVPMajorType_Image;

	// Our GUID to uniquely identify us to DOpus
	lpVPInfo->idPlugin = GUIDPlugin_WebP;
	return TRUE;
}

BOOL DVP_IdentifyFileBytesW(HWND hWnd, LPTSTR lpszName, LPBYTE lpData, UINT uiDataSize, LPVIEWERPLUGINFILEINFO lpVPFileInfo, DWORD dwStreamFlags)
{
	// https://developers.google.com/speed/webp/docs/api
	if (WebPGetInfo(lpData, uiDataSize, NULL, NULL)) {return TRUE;}
	else {return 0;}
};

It's definitely a .Net DLL; I noticed this before but assumed it was intentional.