Can't Package and cook the game version 4.11.2

This still exists in 4.14, no plugins apart my C++ code. Everything works in standalone. Some more info about the problem in error message instead undefined undefined undefined would be nice. Thanks.

The problem was in my Actor constructor, I started a thread there via singleton which apparently is forbidden, which actually is very good approach. Mea culpa. Moved code to BeginPlay and now everything packages as a charm. By the way, Editor indeed thrown that problem too but at that stage it was just a warning, so check out your logs.

Anyway a stack trace in the error message would be useful :slight_smile:

I spent a solid week working on finding this…very subtle and terrible thing but I found at least one way you can get this error when packaging and one way to solve it. Here is hoping these saves others the time sink in hunting this down.

This error can be 100% unrelated to your code in Unreal and 100% due to a binary dll a thirdparty gives you (or you write yourself as in my case…if I hadn’t been in control of the offending DLL I never would have been able to resolve this). But any dependent windows dll can cause this issue.

In short, if your project is using a binary DLL for Windows AND that DLL was created by liking to the multithreaded DLL runtime library for MSVC (/MD, this is the default BTW), you may get this error when packaging a project that uses that DLL. The fix for this is to compile the binary with the /MT flag so that it links statically with the msvc runtime and is not dependent on the MSVC runtime DLLs.

This issue will not manifest itself in an Development Editor build/run, but will only appear when packaging your windows application. I didn’t go deeply into the specifics of what is going on with the packager (talk about not documented), but it is likely that the package process rebuilds your project with flags that complicate the linkage and compromise the loading of that dll from the project’s exe host…and you get that error as a result. The packager actually attempts to load and run your dll (to test it maybe?) and when it does so…very bad things. I traced things with “Process Monitor/procmon.exe” (if you don’t know this utility, get to know it) and you can see werfault.exe get called, that’s the windows segfault reporter…so something got kernel-murdered when it tries to load the dll…

I fixed it by recompiling the DLL with /MT instead of /MD. Now, all good…packages happily.

But this pathology kind of fits with issues others are experiencing…the fact that some plugins need to be disabled to package the game makes me think 1) these plugins are for editor use and were compiled by the developed with the /MD option because that is the default in visual studio and what the publisher used 2) that setting works fine Editor builds and 3) these plugins were never intended to be packaged with the game (and the developers never attempted to do that so were unaware of the issue).

Anyway, probably not the only reason this error occurs, but definitely one possible reason and certainly the issue I was having. Epic would do well to attempt the load dll in a seperate commandlet so that an exception would not tear down the process and would give them an opportunity to log what is going on. Had such a hypothetical log said “attempting to load dll…” and then “oh no, dll failed load, did you check to make sure you used the right build options?” I would be a week further in my development life…

While a possible workaround, this doesn’t provide an answer. I think I have found a more general answer and solution…see the bottom of this thread and, meanwhile, yell at the publisher of the offending plugin and say, “you need to compile that with /MT and NOT /MD so it statically links to the MSVC runtime”…see more in my comment later.

Wow that’s awesome find gbrill! Thank you for sharing!

#:heart:

Rama

For completeness sake I’ve found the actual cause of this, it’s trivial but was a pain to find.

As already mentioned, you can disable the CRT checks but you will lose the code that will check for any malformed strings. The real problem is caused by UE forcing stdout to UTF-8, when packaging, I’m not sure why this is needed.

When stdout is set to UTF-8, you can’t use printf or std::cout, it will fail this check _VALIDATE_STREAM_ANSI_RETURN.

The correct fix would be to replace printf / std::cout with wprintf / std::wcout, you can change any %s instanced in your printf calls to %hs to avoid having to change more code than needed. If it’s a third-party supplied dll/lib, it might be worth relaying the information.

Interestingly enough (I posted this initially on UDN) why InvalidParameterHandler gets NULL replies back from the offending code is a mystery, it wasn’t until I isolated the code and got valid data I knew what was happening. I’m not sure with the static/dynamic linking, one would have CRT checking (depending on CRT checking enabled or not) enabled and one wouldn’t so hides the issue rather than fixes it.

printf can print full character ranges 0-255 (I think) therefore it would be a problem for a UTF-8 code page as I don’t think there’s any translation for it. So you could still get errors along the way depending on what is being printed, time of day, whether you had breakfast etc. :slight_smile:

But, a sample rig is thus.

#include <stdio.h>
#include <tchar.h>
#include <stdlib.h>  
#include <fcntl.h>
#include <io.h>

void InvalidParameterHandler(
	wchar_t const* Expression,
	wchar_t const* Function,
	wchar_t const* File,
	unsigned int Line,
	uintptr_t Reserved)
{
	__asm int 3;
}

int main()
{
	_set_invalid_parameter_handler(InvalidParameterHandler);
	_setmode(_fileno(stdout), _O_U8TEXT);	// UE4 sets this when packaging via the editor or UFE by setting -utf8output.

	_tprintf(_T("might work\n"));			// won't work if compiled as multi-byte, will if compiled as UNICODE.
	wprintf(L"works\n");
	printf("doesn't work\n");
    return 0;
}

Thanks for finding this, it is super interesting to know…it may have a little to do with what I was saying earlier about that static vs dynamical liking of the common runtime which is one solution to this issue (though I appreciate not everyone has the opportunity to rebuild their third party libraries).

I can imagine the presence of printf/cout requiring linking with a function in a C runtime dynamic library that triggers this check, hence the error. But if the third party library/DLL we are trying to use links statically with the C runtime libraries, perhaps, the error check isn’t necessary: after all, in that case, we are not asking Unreal to link with the offending library and provide it with necessary runtime functions as is the case with dynamic linking/dlls…in the case where you build your thirdparty library with a static link to the c/runtime and create a DLL then Unreal packager no longer has that responsibility.

Or not. I dunno.

Thank you all for your suggestions and solutions, will try on 4.14.3 tomorrow morning, wil return with confirmation if it worked. If we work together we’ll find a solution for almost everything :). I use substance plugin and sometimes Dungeon Architect from plugins and I think at least substance is reliable and works well on other engines like unity
.

Hmm. Well, this all seems to jive to me…and you are likely correct that the mere presence of these function calls is likely bad mojo…I think in the ideal case no one should have printf/cout code living in a module, unicode or not…but of course during the development of the module or library, we all do it…I think this is a big argument to devs of all stripes, plugin or straight-unreal: preprocess out your logging stuff.

Of course, I like to remap stdout/err handles to UE_LOG… So I guess, in that case, make sure we are dealing with TCHAR…ANSI=bad news.

Thanks again for looking into this…I started on the path, but lacked the endurance once I found a “fix”. But now the issue actually makes sense…

No problem, I had to find the issue, as it was a third party lib linked in to a module causing the problem, luckily we were able to modify the source locally to fix it, but with other 3rd party libraries it may require contacting the vendor to supply a fix.

Hello Rama,i am according to your A new, community-hosted Unreal Engine Wiki - Announcements - Epic Developer Community Forums
the tutorial Express set the Third party lib RunTimeLibrary MD…

I just tried it,printf UE_LOG are Noted,The Packet success!!

I’ve got recently the same error. I couldn’t package my game because of a printf() on a third party plugin. But after few day we find out a simple solution to avoid the error and package or game (we are in4.26.2). Like it was said when you cook, the engine forcing stdout to UTF-8, but its an option that can be remove.

in engine code,
In MainFrameActions.cpp, in the function PackageProject
change :

FString CommandLine = FString::Printf(TEXT("-ScriptsForProject="%s" BuildCookRun %s%s -nop4 -project="%s" -cook -stage -archive -archivedirectory="%s" -package -ue4exe="%s" %s -utf8output"),

with

FString CommandLine = FString::Printf(TEXT("-ScriptsForProject="%s" BuildCookRun %s%s -nop4 -project="%s" -cook -stage -archive -archivedirectory="%s" -package -ue4exe="%s" %s"),

and in the same file, in the function CookContent, change :

FString CommandLine = FString::Printf(TEXT("-ScriptsForProject="%s" BuildCookRun %s%s -nop4 -project="%s" -cook -skipstage -ue4exe="%s" %s -utf8output"),

with

FString CommandLine = FString::Printf(TEXT("-ScriptsForProject="%s" BuildCookRun %s%s -nop4 -project="%s" -cook -skipstage -ue4exe="%s" %s"),

and
in LauncherWorker, function CreateUATCommand, change :

FString UATCommand = TEXT(" -utf8output");

with

FString UATCommand = TEXT("");

with the modification we were able to package our game.

1 Like

Thanks! This thread is gold.