[GH-ISSUE #4241] VS 2013 RTM,many games crash on startup with X64 release build

kerem commented

2026-03-18 03:00:36 +03:00

Owner

Originally created by @daniel229 on GitHub (Oct 19, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/4241

X64 debug build works fine,win32 release and debug build work fine.
crashed games list :
7th dragon 2020 2 JPN
Kingdom Heart BBS FM JPN
Fate Extra CCC JPN
Sword Art Online JPN
Dragon Ball Tag Versus JPN
ETC.

Originally created by @daniel229 on GitHub (Oct 19, 2013). Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/4241 X64 debug build works fine,win32 release and debug build work fine. crashed games list : 7th dragon 2020 2 JPN Kingdom Heart BBS FM JPN Fate Extra CCC JPN Sword Art Online JPN Dragon Ball Tag Versus JPN ETC. ![01](https://f.cloud.github.com/assets/3481559/1365549/5e243f48-386f-11e3-862a-18eb3d37fc34.png)

kerem

2026-03-18 03:00:36 +03:00

closed this issue
added the
Platform-specific (Windows)
label

kerem commented

2026-03-18 03:00:53 +03:00

Author

Owner

@hrydgard commented on GitHub (Oct 19, 2013):

Hm, I think we had some pretty bad memory overwrite around this code a while ago... maybe the new optimizer in 2013 changes the order of things in memory, exposing some new overwrite that we just didn't notice before.

Needs investigation indeed.

@hrydgard commented on GitHub (Oct 19, 2013): Hm, I think we had some pretty bad memory overwrite around this code a while ago... maybe the new optimizer in 2013 changes the order of things in memory, exposing some new overwrite that we just didn't notice before. Needs investigation indeed.

kerem commented

2026-03-18 03:00:58 +03:00

Author

Owner

@thedax commented on GitHub (Oct 19, 2013):

Kingdom Heart BBS FM JPN

That one's not crashing for me with VS2013 RTM..bad game ISO perhaps? Unfortunately, I don't have any of the other games listed, but in my experience I've seen zero crashes with my x64 release build so far. Maybe make sure you're not using any crazy optimisation settings.

@thedax commented on GitHub (Oct 19, 2013): > Kingdom Heart BBS FM JPN That one's not crashing for me with VS2013 RTM..bad game ISO perhaps? Unfortunately, I don't have any of the other games listed, but in my experience I've seen zero crashes with my x64 release build so far. Maybe make sure you're not using any crazy optimisation settings.

kerem commented

2026-03-18 03:01:03 +03:00

Author

Owner

@daniel229 commented on GitHub (Oct 20, 2013):

I have not changed anything except update Visual C++ compiler and libraries.I think these ISOs are not bad dumps.The stack traces are the same when they crashes,and these games all need PGD decrypted.

@daniel229 commented on GitHub (Oct 20, 2013): I have not changed anything except update Visual C++ compiler and libraries.I think these ISOs are not bad dumps.The stack traces are the same when they crashes,and these games all need PGD decrypted.

kerem commented

2026-03-18 03:01:08 +03:00

Author

Owner

@thedax commented on GitHub (Oct 20, 2013):

Oh, right, I forgot: I use an english patched ISO(I patched it myself from Japanese), so the PGD stuff is probably not an issue for me..is yours not touched in any way?

@thedax commented on GitHub (Oct 20, 2013): Oh, right, I forgot: I use an english patched ISO(I patched it myself from Japanese), so the PGD stuff is probably not an issue for me..is yours not touched in any way?

kerem commented

2026-03-18 03:01:13 +03:00

Author

Owner

@daniel229 commented on GitHub (Oct 20, 2013):

One of my games still crashes with PGD decrypted.

@daniel229 commented on GitHub (Oct 20, 2013): One of my games still crashes with PGD decrypted.

kerem commented

2026-03-18 03:01:18 +03:00

Author

Owner

@solarmystic commented on GitHub (Oct 20, 2013):

I'd like to chime in that Kingdom Heats BBS: FM (JP, english patched edition I have) also crashes using an x64 release build I compiled with MSVC 2013 RTM Express. No crazy settings used, just the defaults, and the project files upgraded to MSVC 2013.

Stack trace from x64 release build on MSVC 2013:

>   PPSSPPWindows64.exe!sceDrmBBMacFinal(MAC_KEY * mkey, unsigned char * buf, unsigned char * vkey) Line 258    C
    PPSSPPWindows64.exe!sceDrmBBMacFinal2(MAC_KEY * mkey, unsigned char * out, unsigned char * vkey) Line 313   C
    PPSSPPWindows64.exe!pgd_open(unsigned char * pgd_buf, int pgd_flag, unsigned char * pgd_vkey) Line 642  C
    PPSSPPWindows64.exe!__IoIoctl(unsigned int id, unsigned int cmd, unsigned int indataPtr, unsigned int inlen, unsigned int outdataPtr, unsigned int outlen) Line 1932    C++
    PPSSPPWindows64.exe!WrapU_UUUUUU<&sceIoIoctl>() Line 732    C++
    PPSSPPWindows64.exe!CallSyscall(Memory::Opcode op) Line 450 C++
    [External Code]

Locals:

+       mkey    0x0000000000000006 {type=??? key=0x000000000000000a <Error reading characters of string.> pad=0x000000000000001a <Error reading characters of string.> ...} MAC_KEY *
+       buf 0x0000000003e5e1f0 "Á\x11Ú,ð\xefªêÝ`žî¦üŠ"   unsigned char *
+       vkey    0x0000000000000000 <NULL>   unsigned char *
+       tmp1    0x0000000003e5e0a0 "[nŸ§’ªSœ«ÞX2I–f(...   unsigned char[16]
+       tmp 0x0000000003e5e0a0 "[nŸ§’ªSœ«ÞX2I–f(...   unsigned char[16]

Tried to get a stacktrace from an x64 debug build using MSVC 2013, but it works fine, just like @daniel229 reported earlier on. Win32 and Win32 Debug builds also work fine, strangely enough.

Also works perfectly fine on the latest buildbot builds (both 32bit and 64bit) that are currently compiled with MSVC 2010.

Quite strange, since other games I have do not exhibit this issue when PPSSPP is compiled with MSVC 2013 RTM.

@solarmystic commented on GitHub (Oct 20, 2013): I'd like to chime in that Kingdom Heats BBS: FM (JP, english patched edition I have) also crashes using an x64 release build I compiled with MSVC 2013 RTM Express. No crazy settings used, just the defaults, and the project files upgraded to MSVC 2013. Stack trace from x64 release build on MSVC 2013: ``` > PPSSPPWindows64.exe!sceDrmBBMacFinal(MAC_KEY * mkey, unsigned char * buf, unsigned char * vkey) Line 258 C PPSSPPWindows64.exe!sceDrmBBMacFinal2(MAC_KEY * mkey, unsigned char * out, unsigned char * vkey) Line 313 C PPSSPPWindows64.exe!pgd_open(unsigned char * pgd_buf, int pgd_flag, unsigned char * pgd_vkey) Line 642 C PPSSPPWindows64.exe!__IoIoctl(unsigned int id, unsigned int cmd, unsigned int indataPtr, unsigned int inlen, unsigned int outdataPtr, unsigned int outlen) Line 1932 C++ PPSSPPWindows64.exe!WrapU_UUUUUU<&sceIoIoctl>() Line 732 C++ PPSSPPWindows64.exe!CallSyscall(Memory::Opcode op) Line 450 C++ [External Code] ``` Locals: ``` + mkey 0x0000000000000006 {type=??? key=0x000000000000000a <Error reading characters of string.> pad=0x000000000000001a <Error reading characters of string.> ...} MAC_KEY * + buf 0x0000000003e5e1f0 "Á\x11Ú,ð\xefªêÝ`žî¦üŠ" unsigned char * + vkey 0x0000000000000000 <NULL> unsigned char * + tmp1 0x0000000003e5e0a0 "[nŸ§’ªSœ«ÞX2I–f(... unsigned char[16] + tmp 0x0000000003e5e0a0 "[nŸ§’ªSœ«ÞX2I–f(... unsigned char[16] ``` ![capture](https://f.cloud.github.com/assets/4345150/1367975/cf841766-396f-11e3-87d8-4de6da3fab3c.PNG) Tried to get a stacktrace from an x64 debug build using MSVC 2013, but it works fine, just like @daniel229 reported earlier on. Win32 and Win32 Debug builds also work fine, strangely enough. Also works perfectly fine on the latest buildbot builds (both 32bit and 64bit) that are currently compiled with MSVC 2010. Quite strange, since other games I have do not exhibit this issue when PPSSPP is compiled with MSVC 2013 RTM.

kerem commented

2026-03-18 03:01:23 +03:00

Author

Owner

@daniel229 commented on GitHub (Oct 23, 2013):

change /O2 to /Od,It works again, X64 build can not use /O1,/02,Ox optimization in vs2013.

@daniel229 commented on GitHub (Oct 23, 2013): change /O2 to /Od,It works again, X64 build can not use /O1,/02,Ox optimization in vs2013. ![01](https://f.cloud.github.com/assets/3481559/1388545/4d496fb4-3bc0-11e3-8a4a-4f933d6678c0.png)

kerem commented

2026-03-18 03:01:28 +03:00

Author

Owner

@daniel229 commented on GitHub (Oct 23, 2013):

Only need disable optimization in project libkirk.

@daniel229 commented on GitHub (Oct 23, 2013): Only need disable optimization in project libkirk.

kerem commented

2026-03-18 03:01:33 +03:00

Author

Owner

@hrydgard commented on GitHub (Oct 23, 2013):

Ah good! Thanks for investigating.

libkirk has some gnarly code..

@hrydgard commented on GitHub (Oct 23, 2013): Ah good! Thanks for investigating. libkirk has some gnarly code..

kerem commented

2026-03-18 03:01:38 +03:00

Author

Owner

@hrydgard commented on GitHub (Oct 23, 2013):

If you want to investigate more, you can put this in various places in the code, and see if you can narrow it down:

#pragma optimize( "", off )

Every function below that pragma will not be optimized. So you can turn on optimization, put that at the top of a suspicious file and see if it fixes it. If it does, move it down the file until it breaks - the last function will be the one that gets miscompiled with optimization.

@hrydgard commented on GitHub (Oct 23, 2013): If you want to investigate more, you can put this in various places in the code, and see if you can narrow it down: #pragma optimize( "", off ) Every function below that pragma will not be optimized. So you can turn on optimization, put that at the top of a suspicious file and see if it fixes it. If it does, move it down the file until it breaks - the last function will be the one that gets miscompiled with optimization.

kerem commented

2026-03-18 03:01:43 +03:00

Author

Owner

@daniel229 commented on GitHub (Oct 23, 2013):

It is the function in amctrl.c.
int sceDrmBBMacFinal(MAC_KEY *mkey, u8 *buf, u8 *vkey){}

@daniel229 commented on GitHub (Oct 23, 2013): It is the function in amctrl.c. int sceDrmBBMacFinal(MAC_KEY *mkey, u8 *buf, u8 *vkey){}

kerem commented

2026-03-18 03:01:49 +03:00

Author

Owner

@daniel229 commented on GitHub (Oct 23, 2013):

It's the sub_158(u8 *buf, int size, u8 *key, int key_type) inside int sceDrmBBMacFinal(MAC_KEY *mkey, u8 *buf, u8 *vkey)

@daniel229 commented on GitHub (Oct 23, 2013): It's the sub_158(u8 *buf, int size, u8 *key, int key_type) inside int sceDrmBBMacFinal(MAC_KEY *mkey, u8 *buf, u8 *vkey)

kerem commented

2026-03-18 03:01:54 +03:00

Author

Owner

@hrydgard commented on GitHub (Oct 23, 2013):

Feel free to send a pull request to turn off optimization in that file until we can figure out in detail what's going wrong.

Either do

 #ifdef _MSC_VER
 #pragma optimize( "", off )
 #endif

at the top, or turn it off in the vcproj. This is not really a speed bottleneck so it's fine if it's not optimized.

@hrydgard commented on GitHub (Oct 23, 2013): Feel free to send a pull request to turn off optimization in that file until we can figure out in detail what's going wrong. Either do ``` #ifdef _MSC_VER #pragma optimize( "", off ) #endif ``` at the top, or turn it off in the vcproj. This is not really a speed bottleneck so it's fine if it's not optimized.

kerem commented

2026-03-18 03:01:59 +03:00

Author

Owner

@daniel229 commented on GitHub (Oct 23, 2013):

only disable in vs2013?

#ifdef _MSC_VER
#if (_MSC_VER == 1800)
#pragma optimize( "", off )
#endif
#endif

@daniel229 commented on GitHub (Oct 23, 2013): only disable in vs2013? <pre>#ifdef _MSC_VER #if (_MSC_VER == 1800) #pragma optimize( "", off ) #endif #endif </pre>

kerem commented

2026-03-18 03:02:04 +03:00

Author

Owner

@hrydgard commented on GitHub (Oct 23, 2013):

sure :)

@hrydgard commented on GitHub (Oct 23, 2013): sure :)

kerem commented

2026-03-18 03:02:09 +03:00

Author

Owner

@xsacha commented on GitHub (Dec 3, 2013):

This issue is the same as https://github.com/hrydgard/ppsspp/issues/3411
So it affects some 64-bit GCC as well when -O3.

From the 'Locals' output, this looks very suspicious:

  tmp1    0x0000000003e5e0a0 "[nŸ§’ªSœ«ÞX2I–f(...   unsigned char[16]

  tmp 0x0000000003e5e0a0 "[nŸ§’ªSœ«ÞX2I–f(...   unsigned char[16]

Apparently tmp1 = tmp. Although tmp1 has never been used before other than a memcpy. So why does it have the same address as tmp?

@xsacha commented on GitHub (Dec 3, 2013): This issue is the same as https://github.com/hrydgard/ppsspp/issues/3411 So it affects some 64-bit GCC as well when -O3. From the 'Locals' output, this looks very suspicious: - tmp1 0x0000000003e5e0a0 "[nŸ§’ªSœ«ÞX2I–f(... unsigned char[16] - tmp 0x0000000003e5e0a0 "[nŸ§’ªSœ«ÞX2I–f(... unsigned char[16] Apparently tmp1 = tmp. Although tmp1 has never been used before other than a memcpy. So why does it have the same address as tmp?

kerem commented

2026-03-18 03:02:14 +03:00

Author

Owner

@hrydgard commented on GitHub (Dec 5, 2013):

@xsacha, yeah that can't be good. bizarre. optimizer bug? could try declaring one of them or both volatile...

@hrydgard commented on GitHub (Dec 5, 2013): @xsacha, yeah that can't be good. bizarre. optimizer bug? could try declaring one of them or both volatile...

kerem commented

2026-03-18 03:02:19 +03:00

Author

Owner

@daniel229 commented on GitHub (Jan 21, 2014):

Still existed in Visual Studio 2013 Update 1

@daniel229 commented on GitHub (Jan 21, 2014): Still existed in Visual Studio 2013 Update 1

kerem commented

2026-03-18 03:02:24 +03:00

Author

Owner

@daniel229 commented on GitHub (May 13, 2014):

Still presented on update 2

@daniel229 commented on GitHub (May 13, 2014): Still presented on update 2

kerem commented

2026-03-18 03:02:29 +03:00

Author

Owner

@daniel229 commented on GitHub (Aug 3, 2015):

Fixed in update 5.

@daniel229 commented on GitHub (Aug 3, 2015): Fixed in update 5.

kerem commented

2026-03-18 03:02:34 +03:00

Author

Owner

@gamelaster commented on GitHub (Aug 4, 2015):

Yup, Fixed on Update 5/VS2015

@gamelaster commented on GitHub (Aug 4, 2015): Yup, Fixed on Update 5/VS2015

kerem commented

2026-03-18 03:02:39 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Dec 20, 2015):

Should we close this then?

-[Unknown]

@unknownbrackets commented on GitHub (Dec 20, 2015): Should we close this then? -[Unknown]

Rows
Columns

[GH-ISSUE #4241] VS 2013 RTM,many games crash on startup with X64 release build #1725