Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Can't use 64bit wavpack in windows 10. (Read 20914 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Can't use 64bit wavpack in windows 10.

Reply #26
So... the base address of wavpack.exe is 0x400000. The fault offset is 0x00007ff8c9c2ed90, so the fault address is 0x7FF8CA02ED90 (correct me if I'm wrong). But there's nothing at this addredd. The only thing above 0x80000000 is ntdll.dll, but it starts at 0x7FF8CC140000.
Don't know what it means. On my computer, there's nothing above 0x80000000 because wavpack doesn't have LargeAddressAware flag.

I took the official wavpack.exe and set this flag in its header. Maybe this will prevent it from crashing?

Can't use 64bit wavpack in windows 10.

Reply #27
So... the base address of wavpack.exe is 0x400000. The fault offset is 0x00007ff8c9c2ed90, so the fault address is 0x7FF8CA02ED90 (correct me if I'm wrong). But there's nothing at this addredd. The only thing above 0x80000000 is ntdll.dll, but it starts at 0x7FF8CC140000.
Don't know what it means. On my computer, there's nothing above 0x80000000 because wavpack doesn't have LargeAddressAware flag.

I took the official wavpack.exe and set this flag in its header. Maybe this will prevent it from crashing?

yes, it prevent it from crashing! 

 

Can't use 64bit wavpack in windows 10.

Reply #28
IMHO it's really strange that wavpack crashes just because this flag in its header was not set. It shouldn't. And it works without problems on many other systems.

Anybody knows what can cause such problems?

Added: found this question, without answers: http://forum.sysinternals.com/vmmap-crash-...topic30356.html

Can't use 64bit wavpack in windows 10.

Reply #29
Yeah, it's certainly not clear what's going on here. WavPack does not use a lot of memory and if you just type “wavpack” it does not allocate any memory at all. There are a few system calls which I tried to eliminate in the special version I created above, but unfortuately missed one. And of course in the 64-bit version all pointers are going to be 64-bits wide, so the flag should be obsolete now (unless someone ported code that stores pointers in hard-coded 32-bit integers, which is very poor design).

I did find somewhere that the LargeAddressAware flag should be set by default in MSVC for 64-bit applications (which makes sense), but that if it's not then the only disadvantage is that an application can't allocate more than 2 GB (which WavPack would never get near). Sounds like this crash, especially given lvqcl's unanswered link, might be a system issue (the code to load 64-bit applications with LargeAddressAware:NO probably doesn't get tested much).

Anyway, it's easy enough to set that bit as it should be and be done with it. Thanks so much to samidare1234 for reporting this and, again, to lvqcl (and the others) for all your help!

Can't use 64bit wavpack in windows 10.

Reply #30
And of course in the 64-bit version all pointers are going to be 64-bits wide, so the flag should be obsolete now


Probably this setting was copied from settings for 32-bit exe files into the settigs for 64-bit project?

Can't use 64bit wavpack in windows 10.

Reply #31
Probably this setting was copied from settings for 32-bit exe files into the settigs for 64-bit project?

Yeah, that's probably what happened. I certainly never [re]set it intentionally.

Can't use 64bit wavpack in windows 10.

Reply #32
When I open wavpack.sln in MSVS 2013, the following linker options are not default (Release,x64):

Enable Incremental Linking: No (/INCREMENTAL:NO)
Generate Debug Info: No
SubSystem: Console (/SUBSYSTEM:CONSOLE)
Enable Large Addresses: No (/LARGEADDRESSAWARE:NO)
References: Yes (/OPT:REF)
Enable COMDAT Folding: Yes (/OPT:ICF)
Randomized Base Address: No (/DYNAMICBASE:NO)
Target Machine: MachineX64 (/MACHINE:X64)

Can't use 64bit wavpack in windows 10.

Reply #33
Visual Studio sets those for new projects release configuration except for debug and machine.  Dynamic base default is off in 08 so its probably getting set when upgrading.
And of course in the 64-bit version all pointers are going to be 64-bits wide, so the flag should be obsolete now (unless someone ported code that stores pointers in hard-coded 32-bit integers, which is very poor design).

Windows wouldn't be Windows without bad software

Can't use 64bit wavpack in windows 10.

Reply #34
I could replicate the crash samidare1234 reported on English Windows 10 by installing EMET and marked wavpack.exe to get protected by all the default mitigations.
I tested the behavior on some other random x64 programs where protecting them with EMET alone showed no issues but once largeaddressaware bit was altered they instantly crashed. So I too agree that changing the header bit is all you need to do.

Can't use 64bit wavpack in windows 10.

Reply #35
Quote
The price of paranoia is eternal vigilance.

Can't use 64bit wavpack in windows 10.

Reply #36
When I open wavpack.sln in MSVS 2013, the following linker options are not default (Release,x64):

Enable Incremental Linking: No (/INCREMENTAL:NO)
Generate Debug Info: No
SubSystem: Console (/SUBSYSTEM:CONSOLE)
Enable Large Addresses: No (/LARGEADDRESSAWARE:NO)
References: Yes (/OPT:REF)
Enable COMDAT Folding: Yes (/OPT:ICF)
Randomized Base Address: No (/DYNAMICBASE:NO)
Target Machine: MachineX64 (/MACHINE:X64)

Thanks, most of these make sense. I either changed them to allow the programs to link (/INCREMENTAL) or are obvious (/SUBSYSTEM:CONSOLE, although probably the library and DLL do not need this).

However, I don't understand MachineX64. Obviously that must be set the way it is to generate x64 code, right?

Quote from: case link=msg=0 date=
I could replicate the crash samidare1234 reported on English Windows 10 by installing EMET and marked wavpack.exe to get protected by all the default mitigations.
I tested the behavior on some other random x64 programs where protecting them with EMET alone showed no issues but once largeaddressaware bit was altered they instantly crashed. So I too agree that changing the header bit is all you need to do.

Thanks for trying this out case; it's reassuring to know it's not just me.... 

BTW, I assume that the random x64 programs you tried did not try to allocate over 2GB of memory; that would obviously make them crash (well, or fail gracefully) with LAA.

Can't use 64bit wavpack in windows 10.

Reply #37
I have to say, those Windows tools are completely fringe to me.

I use MinGW-w64 to cross-compile binaries (both win32 and win64) for my program. Do I need to check for anything (other than SIZE_MAX)?

Can't use 64bit wavpack in windows 10.

Reply #38
When I open wavpack.sln in MSVS 2013, the following linker options are not default (Release,x64):

Thanks, most of these make sense. I either changed them to allow the programs to link (/INCREMENTAL) or are obvious (/SUBSYSTEM:CONSOLE, although probably the library and DLL do not need this).

However, I don't understand MachineX64. Obviously that must be set the way it is to generate x64 code, right?


By "not default" I meant that these options have some defined values (denoted as bold font), not just <inherit from parent or project defaults>.

Can't use 64bit wavpack in windows 10.

Reply #39
Hi, had the same problem with the DirectShow Filter (CoreWavPack 1.2.0) and Windows 10. Change to 32bit solved the problem.

Thanks

Can't use 64bit wavpack in windows 10.

Reply #40
By "not default" I meant that these options have some defined values (denoted as bold font), not just <inherit from parent or project defaults>.
Ah, okay. That makes sense now.

Hi, had the same problem with the DirectShow Filter (CoreWavPack 1.2.0) and Windows 10. Change to 32bit solved the problem.
Thanks for letting me know. I haven't rebuilt the DirectShow filters for a while, but I will definitely do that once I've fixed this issue in the configuration.