Hello,

Enjoying the series so far, early days though. It's been good going up until today. I just finished watching Day 22, with the live code editing, and ran into a minor problem that I can't seem to fathom.

I'm using Visual Studio Community 2015, and it seems unable to load the updated code instantaneously. Is this just a symptom of a later version of Visual Studio, or am I missing something?

In the output window I see the following -

BTL:46216 TC:51976 BTW:5760 - PC:36616 WC:42376 DELTA:5760 (0.030000s)
34.04ms/f, 0.00f/s, 116.13mc/f
'win32_handmade.exe' (Win32): Unloaded 'D:\Handmade_Hero\build\handmade_temp.dll'
'win32_handmade.exe' (Win32): Loaded 'D:\Handmade_Hero\build\handmade_temp.dll'. Symbols loaded.
BTL:51976 TC:59656 BTW:7680 - PC:44296 WC:50056 DELTA:5760 (0.030000s)
33.33ms/f, 0.00f/s, 112.84mc/f
BTL:59656 TC:65416 BTW:5760 - PC:50056 WC:55816 DELTA:5760 (0.030000s)
33.72ms/f, 0.00f/s, 115.01mc/f
'win32_handmade.exe' (Win32): Unloaded 'D:\Handmade_Hero\build\handmade_temp.dll'
'win32_handmade.exe' (Win32): Loaded 'D:\Handmade_Hero\build\handmade_temp.dll'. Cannot find or open the PDB file.
BTL:65416 TC:88456 BTW:23040 - PC:73096 WC:78856 DELTA:5760 (0.030000s)
2888.12ms/f, 0.00f/s, 9820.56mc/f
BTL:88456 TC:88456 BTW:0 - PC:73096 WC:78856 DELTA:5760 (0.030000s)
33.33ms/f, 0.00f/s, 113.15mc/f

I'm not exactly sure why it's attempting to unload and load the dll twice, or why that delay creeps in.

I found this tweet from the same night as the stream that suggested a newer version of Visual Studio would prevent dynamic code loading under the debugger. Is that what's happening here?

Apologies if this has been done to death by now - I realise the majority of you have moved on somewhat. My searches on this forum didn't turn anything up, so I figured I'd ask. Thanks in advance.

I'm not aware of anything that would prevent dll reloading to work in VS2015. Afaik it should work same as for VS2013.

I don't remember which day, but Casey made build.bat to create different pdb file for every build (%RANDOM% variable in bat file). So when you need to compile new build, you will get new pdb file, and it won't matter that debugger has locked down old pdb file.

Do you have %RANDOM% for -PDB argument in .bat file?

I'm using VS2015 and it seems to work fine for me. Make sure your build.bat is correct!

Including %random% in the -PDB option results in the same behaviour. And as far I can see my build.bat file is the same.

Removing the -Z7 option from the compiler flags results in an instantaneous change, but then no .pdb file is produced and the VS debugging no longer functions.

I guess if others are having no trouble with VS 2015 I'll try re-watching the video. Maybe I missed something.

Have you started using the lock file yet? In later episodes we use a lock file to ensure that the PDB has been written before the executable gets reloaded.

- Casey

I haven't got to the lock file yet. I'll power through and see what happens. Thanks.

Judging by the log you posted, I would suspect that the lock file fixes it.

- Casey

I think I have a similar problem but I cant find the episode you are talking about where you start using a 'lock file'... any estimate to which episode that would be?

thanks

It's here.

I already found it after some more digging and the lock file does the trick :D thx tho!