[solved] version 1.16.0 not working in Windows XP

[Username1267]

Hello and welcome to the scene,
as you probably noticed there is a new version out (1.16.0). This version has the same problem like the previous version (1.15.4), that it cannot be used in Windows XP anymore. The last known version which works out of the box in Windows XP is 1.15.3.

We got the previous version (1.15.4) working in Windows XP by replacing the libffm.dll with a hacked one (see separate forum topic). But the new version (1.16.0) does not need this hack because it has this issue fixed, but it has a different problem.

When you try to start the graphical user interface (makemkv.exe) then the program will tell you, that it can't find it's console application (makemkvcon.exe).

cant_find.png (4.59 KiB) Viewed 15389 times

In the previous version (1.15.4) with no hack the console application (makemkvcon.exe) could not start and therefore you got an initialization error, too. But in the new version (1.16.0) the console application (makemkvcon.exe) does start if you try to manually.

Did anyone do some further investigation so we can fix this issue and get the new version (1.16.0) running in Windows XP?

[Username1267]

My analysis so far is, that makemkv.exe calls kernel32.dll/CreateNamedPipeW to open a connection with writing access to a pipe which is supposed to be connected with makemkvcon.exe. But the function fails with ERROR_INVALID_PARAMETER. Then makemkv.exe shows the error message and terminates itself afterwards.

[wtuppa]

This is not a problem of Windows XP only. I have the same error message on my Windows 10 Home (20H2). I tried to install MakeMKV in german and english. Last known version working for me was 1.15.2.

[Username1267]

Thank you for this information. This saves me a lot of work because I thought it was a Windows XP specific problem.

[wtuppa]

Tried once more and I see, that my error message is a little bit different: NO_ANSWER_FROM_MAKEMKVCON. But it fails to initialiaze the application with just that window.

[Username1267]

If I remember correctly there are 4 different error messages you can get at this stage of the loading process. They all seem to be triggered by a failed pipe connection in one way or another.

I tried to get version 1.16.0 running by either using makemkv.exe or makemkvcon.exe from the 1.15.4 package. This seemed to have revealed that the error is in makemkv.exe.

A comparision of the 1.15.4 makemkv.exe and the 1.16.0 makemkv.exe might reveal more. Especially if we look at the values of the input parameters that makemkv.exe feeds to kernel32.dll/CreateNamedPipeW.

[mike admin]

MakeMKV (GUI) is open-source. There was major rewrite in 1.16.0 of GUI-con communication protocol, which unfortunately involved API change, so you can't mix 1.16 GUI/console/MMBD with previous versions. Hopefully, this is the last ABI change.

The function below is now used instead of CreateNamedPipe in previous versions, as makemkv now uses asynchronous pipes on windows. I am unable to reproduce problem, even on XP.

Code: Select all

static ULONG volatile g_ApPipeId = 0;
static BOOL CreatePipeAsync(PHANDLE hReadPipe,PHANDLE hWritePipe,LPSECURITY_ATTRIBUTES lpPipeAttributesRead,LPSECURITY_ATTRIBUTES lpPipeAttributesWrite,DWORD nSize)
{
    HANDLE hr,hw;
    WCHAR name[64];

    swprintf_s(name, sizeof(name)/sizeof(name[0]), L"\\\\.\\pipe\\LOCAL\\makemkv-%08x-%02x", GetCurrentProcessId(), InterlockedIncrement(&g_ApPipeId));
    hw = CreateNamedPipeW(name, PIPE_ACCESS_OUTBOUND | FILE_FLAG_FIRST_PIPE_INSTANCE | FILE_FLAG_OVERLAPPED,
        PIPE_TYPE_BYTE | PIPE_REJECT_REMOTE_CLIENTS, 1,
        nSize, nSize, 0, lpPipeAttributesWrite);
    if (INVALID_HANDLE_VALUE == hw)
    {
        return FALSE;
    }

    hr = CreateFileW(name, GENERIC_READ | FILE_WRITE_ATTRIBUTES, 0, lpPipeAttributesRead, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);
    if (INVALID_HANDLE_VALUE == hr)
    {
        return FALSE;
    }

    if (0 == ConnectNamedPipe(hw, NULL))
    {
        if (ERROR_PIPE_CONNECTED != GetLastError())
        {
            return FALSE;
        }
    }

    *hReadPipe = hr;
    *hWritePipe = hw;
    return TRUE;
}

[wtuppa]

so what can be done to support you to find the problem?
I am willing to do some tests to get a working version again.

[EarlGrey]

I can confirm the same problem reported by Username1267. I had a disc that wasn't readable with my desktop's DVD drive, but is working on my XP laptop's drive. I don't typically rip from a laptop, so I went to install MakeMKV and ran into this issue. But since I had old installers archived and MakeMKV registered, it wasn't a blocker.

I am running XP Home SP3 (32-bit), with nVIDIA's 266.58 drivers from January 7, 2011.

I wonder if this could be a 32-bit vs 64-bit issue? I have occasionally run into programs that worked on XP Pro x64, but not XP 32-bit, and that could explain both why mike admin didn't run into the issue (if he is on XP x64), and why wtuppa is encountering it on Windows 10 (if it is 32-bit Windows 10). I found Microsoft documentation indicating CreatedNamedPipeA is supported on Win2K and later, but can't find anything definitive on CreateNamedPipeW.

[preserve]

On Windows XP Pro SP3, I got the same error message as Username1267.

(I did install into a custom directory in order to differentiate from previous versions I also have installed. Will uninstall all versions and test default directory tomorrow.)

No issues on Windows 7 Pro SP1 64-bit.

[wtuppa]

I use Windows10 64bit (32GB of main memory, latest version). So definitly not only a problem of 32/64 bit.

[wtuppa]

just found a solution for me:
I use a RAM disk, where my temporary files reside. If I map the temporary directory (TMP, TEMP) to C:\TMP (instead of RAM disk), MakeMKV starts normally without any problems.
I use following RAM disk: SoftPerfect RAM Disk Version 3.4.7 64-bit (last free version). The size is 4095MB.

[wtuppa]

is seems, that only TMP must be modified. I now use the following shortcut:
C:\Windows\System32\cmd.exe /c "SET tmp=C:\tmp&& START /D ^"C:\Program Files (x86)\MakeMKV^" makemkv.exe"

dot forget to set the shell now to minized and change the icon to the usual one (since now it is a shortcut to CMD).

[Username1267]

Hurray, I got it running. A single bit was the cause. Setting the bit to 0 solves the problem.

I just checked the function call and what makemkv.exe is feeding as input parameter values:

Code: Select all

call kernel32.dll/CreateNamedPipeW(
	Name = address_of_2_byte_per_character_string("\\.\pipe\LOCAL\makemkv-00000974-01")
	OpenMode = 0x40080002 (PIPE_ACCESS_OUTBOUND|FILE_FLAG_OVERLAPPED|WRITE_OWNER)
	PipeMode = 8 (PIPE_WAIT|PIPE_READMODE_BYTE|PIPE_TYPE_BYTE|8)
	MaxInstances = 1
	OutBufferSize = 0
	InBufferSize = 0
	DefaultTimeout = 0
	pSecurity = 12F6B0 -> {Length = 12|d, pSecurityDescriptor = NULL, InheritHandle = true}
)

The parameter "PipeMode" has an invalid value. 0x8 = PIPE_REJECT_REMOTE_CLIENTS is not supported in versions of Windows below 10.0 (at least not according to the official documentation).

@mike admin: The GUI is open source? That is nice. Is there any way for outsiders like me to download the source code? BTW: I like your modular approach with the GUI separated from the main program.

@EarlGrey: ASpecificFunctionA and ASpecificFunctionW usually get introduced at the same time. But I can't confirm that CreateNamedPipeA/W was introduced with Windows 2000 without checking because Microsoft sometimes gives intentionally wrong operating systems. When the support for Windows XP was dropped by Microsoft they wrote that a lot of functions need Windows Vista or later. Which was wrong because many of these functions already existed in Windows NT 3.5. But it is possible that they fixed that in their documentation by now. Microsoft also still releases updates for Windows XP from time to time. So the "support drop" is just a marketing thing to get people buying their software again.

[Username1267]

And here is the modified makemkv.exe for the version 1.16.0.

I only tested whether the program starts (which it does). I had no time to do ripping.