Emulator

I will take a look when I have some time. Would be helpful if someone could narrow down what is affected; Does it work in intererpreter? JitIL? if you make some ops fallback? With DSP LLE? etc...

I loaded save 3 and the game seems to play fine (i can run around the island and interact with things). What exactly do you need to do to cause the freeze?

Were you on Windows?

I reproduced the freeze on Windows 7.

Tested and also reproduced this freeze on 8.1

OF COURSE I wasn't on Win7, are you INSANE???

Anyways, the hang is actually the game crashing (for JMC at least):

.text2:80240BB4 sub_80240BB4:
.text2:80240BB4
.text2:80240BB4 .set arg_0,  0
.text2:80240BB4 .set arg_4,  4
.text2:80240BB4
.text2:80240BB4   stwu      r1, -0x20(r1)
.text2:80240BB8   mflr      r0
.text2:80240BBC   stw       r0, 0x20+arg_4(r1)
.text2:80240BC0   addi      r11, r1, 0x20+arg_0
.text2:80240BC4   bl        sub_80328F3C
.text2:80240BC8   mr        r31, r3
.text2:80240BCC   bl        sub_803095EC
.text2:80240BD0   lwz       r0, 0x10(r31)
.text2:80240BD4   cmplwi    r0, 0
.text2:80240BD8   bne       loc_80240BF0
.text2:80240BDC   mr        r3, r31
.text2:80240BE0   lwz       r12, 0xC(r31)
.text2:80240BE4   lwz       r12, 0x20(r12)
.text2:80240BE8   mtctr     r12
.text2:80240BEC   bctrl
.text2:80240BF0
.text2:80240BF0 loc_80240BF0:                           # CODE XREF: sub_80240BB4+24j
.text2:80240BF0   lwz       r3, 0x10(r31)
.text2:80240BF4   cmplwi    r3, 0
.text2:80240BF8   beq       loc_80240EF8
.text2:80240BFC   lwz       r3, 0x10(r3)
.text2:80240C00   lis       r0, 0x8000
.text2:80240C04   cmplw     r3, r0
.text2:80240C08   blt       loc_80240C44
.text2:80240C0C   bl        sub_802C7690
.text2:80240C10   lis       r4, aDynamicmodulec@h       # "DynamicModuleControlBase::link not main"...
.text2:80240C14   addi      r6, r4, aDynamicmodulec@l   # "DynamicModuleControlBase::link not main"...
.text2:80240C18   addi      r4, r6, (aDynamiclink_cp - aDynamicmodulec) # "DynamicModuleControlBase::link not main"...
.text2:80240C1C   li        r5, 0x265
.text2:80240C20   addi      r6, r6, (aMmoduleInfo_se - aDynamicmodulec) # "DynamicModuleControlBase::link not main"...
.text2:80240C24   bl        sub_802C7788
.text2:80240C28   lis       r3, aDynamicmodulec@h       # "DynamicModuleControlBase::link not main"...
.text2:80240C2C   addi      r5, r3, aDynamicmodulec@l   # "DynamicModuleControlBase::link not main"...
.text2:80240C30   addi      r3, r5, (aDynamiclink_cp - aDynamicmodulec) # "DynamicModuleControlBase::link not main"...
.text2:80240C34   li        r4, 0x265
.text2:80240C38   addi      r5, r5, (asc_80363B6F - aDynamicmodulec) # "DynamicModuleControlBase::link not main"...
.text2:80240C3C   crclr     4*cr1+eq
.text2:80240C40   bl        sub_80006C4C                                      <-- calls PPCHalt so you hang forever

This error is "DynamicLink.cpp" line 613 "mModule->info.sectionInfoOffset < 0x80000000".

So...not sure what's up yet. Would be nice if someone on win7 can see why this memory is becoming corrupted (it may also just be mModule pointer which is corrupted...).

Repro'd on Windows 10.

I can't reproduce the crash with an endgame savegame. Using Windows 7, Dolphin 4.0-7538 and Dolphin 4.0-7664 (from the downloads page), DirectX and OpenGL, Wind Waker PAL(50Hz and 60Hz mode).

The only difference i can make out to the people with the crash is that i have an amd gpu. AMD Radeon HD 7790.

NTSC TWW, VS2015 installed (and my own build), Win7, AMD Radeon 5770, blackscreens as soon as I load my save (which appears to be at Windfall)

These were my testing envs. Reproduced on all.

Windows 7 - Haswell CPU - GTX 770 - VS2015 installed
Windows 8.1 - Haswell CPU - GTX 770 - VS2015 installed
Windows 8.1 - Haswell CPU - Haswell GPU - VS2015 not installed (Runtimes installed)
Windows 10 - Haswell CPU - Haswell GPU - VS2015 not installed (Runtimes installed)

build 7538 grabbed from buildbot. Also repro'd with latest.

Could people with the bug check to see if it is dying at the same spot?
It would also be nice if someone with the bug can track where the memory corruption is coming from...

Just to update on the bug, it seems people are hitting the error at the same location, which is good.
Now we just need someone to track the memory corruption... :)

This seems to be a problem with the underlying fseeki64/fread combination.
This hack will fix zelda:

bool DVDRead(u64 _iDVDOffset, u32 _iRamAddress, u32 _iLength, bool decrypt)
{
    unsigned char hexData[16] = {
        0x59, 0x61, 0x7A, 0x30, 0x00, 0x00, 0x34, 0xBC, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
    };

    if (_iDVDOffset == 0x55254578) {
        do {
            s_inserted_volume->Read(_iDVDOffset, _iLength, Memory::GetPointer(_iRamAddress), decrypt);
        } while (memcmp(hexData, Memory::GetPointer(_iRamAddress), sizeof(hexData)));
        return true;
    }
    else {
        return s_inserted_volume->Read(_iDVDOffset, _iLength, Memory::GetPointer(_iRamAddress), decrypt);
    }
}

The issue is that PlainFileReader::Read calls m_file.Seek(offset, SEEK_SET), which is implemented with _fseeki64, and then calls ReadBytes<u8>, which is implemented with fread. For some reason, the first time it has to seek to the file "rels/d_a_obj_ferris.rel", the seek is not done by the time the fread is executed. Thus, the buffer is filled with data from the last location. This is a problem because the first time zelda reads the file is to figure out if it's compressed or not.

After looking a bit more, the issue is specifically caused by the fseek implementation not properly clearing the internal cache, which fread then reads from. Fixing this will probably just be a matter of waiting for MS to push a fixed ucrtbase.dll. I will update this bug with more info once I have it, either way.

So it turns out that when using a compressed iso file(.gcz) it works for me(and MaJoR1 who found out about this), when i use the uncompressed iso file, it freezes like it does for most others as well.

It's not helping anymore, but i think it's still good to know why it worked for some people and did not for others.

In my case, my iso had a completely different layout than other people :) (it had been FSTFIX'd)

godisgovernment wrote:

here is an actual patch file that will fix the problem for all games, which you may use until we know how MS is actually going to fix this...

Hello godisgovernment. If it's not too much to ask, do you think you could include a download link to a compiled version of the latest Dolphin build, with that patch you just posted added in? Myself and many others don't have the know-how to add a patch to a dolphin build, so for us that patch file is practically unusable.

I know there's always the option of using an earlier build, but the latest one has certain features (such as new hotkey options) that I'd like to take advantage of during my Wind Waker play through. I would really appreciate it if you could oblige me.

Cheers

see https://github.com/dolphin-emu/dolphin/pull/3161 and the buildbot builds provided for that PR. the version of the patch is better.

godisgovernment wrote:

see https://github.com/dolphin-emu/dolphin/pull/3161 and the buildbot builds provided for that PR. the version of the patch is better.

Alright, cheers.

godisgovernment wrote:

see https://github.com/dolphin-emu/dolphin/pull/3161 and the buildbot builds provided for that PR. the version of the patch is better.

Tried it and the crash is still occurring for me once I get close to Windfall Island, while it never happened on old builds. Weird.

What did you try exactly? It should be fixed now.
try one of the builds from https://dolphin-emu.org/download/ >= 4.0-8026
if it still doesn't work, find which version of ucrtbase.dll dolphin is loading on your computer and give me some info about it. for example, the file itself, a hash, or the PE header checksum...

For reference, Microsoft Connect report: https://connect.microsoft.com/VisualStudio/Feedback/Details/1631795

godisgovernment wrote:

What did you try exactly? It should be fixed now.
try one of the builds from https://dolphin-emu.org/download/ >= 4.0-8026
if it still doesn't work, find which version of ucrtbase.dll dolphin is loading on your computer and give me some info about it. for example, the file itself, a hash, or the PE header checksum...

Yup, Im on Windows 7 SP1 and 4.0-8032 fixed it. Cheers :D

With Windows 8.1 I still experienced this crash, however after upgrading to windows 10 it didn't occur.

Using 4.0-8032 or later? Can you post the version number of C:\Windows\system32\ucrtbase.dll (Right-click, properties, switch to "Details" and look at the "Product Version" value)

This was using 4.0-8032 with ucrtbase.dll version 10.0.10240.16390

Getting this crash with 4.0-8044 on Windows 8.1, ucrtbase.dll version 10.0.10240.16390.

Please share the file somehow.

@Echo91 Can you try this PR? https://github.com/dolphin-emu/dolphin/pull/3217

Could any of the affected users please try thew following build and report back if the issue has been solved?
https://dl.dolphin-emu.org/prs/pr-3217-dolphin-latest-x64.7z

If not: please include your Windows version, the version of C:\Windows\system32\ucrtbase.dll and - if you can - provide us with the DLL so we can look into it.

I'm running on Mac OSX and the game crashes when I try to go outside at the top of windfall island through the exit that is in that room where you talk to the bird girl... and the exit that is on the bottom floor

bibbydoyo: You're unlikely to get responses by commenting on this old issue. If you've verified that you have a good dump, you can open a new issue. Feel free to ask on the forums if you don't know how to verify your dump or if you simply would like help with your issue there.