What could be causing this crash (?)

Started by
4 comments, last by irreversible 6 years, 4 months ago

I'm adapting the Intel ISPC Texture Compressor into my workflow and I'm experiencing a strange issue.

Basically what is happening is that the first time after building the solution the executable crashes. Except that it doesn't. The following does NOT seem to happen on consecutive runs, but invariably occurs every time I relink:

1) the binary seems to take a fair bit longer to start up (10 or even 15+ seconds). This happens for every instance of the binary (eg the delay occurs again when I copy the exe to a new location). Note that no external files are being referenced other than ispc_texcomp.dll.
2) it then throws the "This program has stopped responding" error for about another 10 seconds. I can close this without stopping execution and it's barely enough time to start up a debug session, which seems to get me nowhere. The notification then goes away and the program executes normally, is if it had been stuck in a tight loop or was run a second time.
3) steps 1 and 2 seem to happen before WinMain is called. Which is to say I can't even step into anything in the debugger before the end of the stall.

Now, the number one thing here is that the code is DX-heavy, which is quite foreign to me. If I had to guess, I'd surmise the problem has to do with some kind of (shader) caching or whatnot by the DX API itself. Except that this seems to (so far) only happen prior to the first run and before any actual program code is called.

The main reason I'm making a fuss about this is because I'm unsure about DX versions and might well be linking against bad modules. Also, the problem could potentially be exacerbated once I start using the tool for batch conversions. I'm using the June 2010 SDK libraries in VS2013, which I fed manually into the project. Can someone maybe download and see if they get similar behavior or suggest what might be causing this?

 

Advertisement

Any reason you're still using Visual Studios 2013?  2015 is free to download and use.  If you're on Windows 8 or above you should be linking against the latest Windows SDK for Direct3D support also.

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

Welp. I just had a walk outside and realized it's probably just ispc_texcomp.dll caching stuff when it gets initialized.  The cache gets invalidated when the module is overwritten. 

 

12 minutes ago, Mike2343 said:

Any reason you're still using Visual Studios 2013?  2015 is free to download and use.  If you're on Windows 8 or above you should be linking against the latest Windows SDK for Direct3D support also.

Yes. Hard drive space.

You could verify by moving the required files to a new directory and seeing what the difference is before and after a test run.  If a file gets larger its caching (or creates a file for that matter).  Might be building lookup tables or something?

It's still not to late to ask Santa: https://www.newegg.com/Product/Product.aspx?Item=N82E16822179010&cm_re=1tb_hard_drive-_-22-179-010-_-Product

;-)

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

27 minutes ago, Mike2343 said:

You could verify by moving the required files to a new directory and seeing what the difference is before and after a test run.  If a file gets larger its caching (or creates a file for that matter).  Might be building lookup tables or something?

It's still not to late to ask Santa: https://www.newegg.com/Product/Product.aspx?Item=N82E16822179010&cm_re=1tb_hard_drive-_-22-179-010-_-Product

;-)

Hehe - thanks, but it's not that. My laptop lacks the extra properietary-looking SATA connector and I'm holding out for a substantial upgrade when Ryzen versions of the new LG and/or Samsung models hopefully come out next year :).

PS - the DLL is cached into memory, at which point it is initialized. By re-linking, the previous file gets overwritten, causing it to be reinitialized when the program is run again after a build. It's just strange to see it stall the main application like that.

This topic is closed to new replies.

Advertisement