Hello,

I've been using GPUView for quite a while on my desktop PC with everything working great. Now I moved to using it on a server machine. I manage to create the etl file, but when I try to view the file, GPUView crashes (it doesn't matter on which computer I view the file, only where I create it). I changed the parameters in the log.cmd script to see what's causing the problem, and narrowed it down to the DXLogger: any etl created with DXLogger crashes GPUView, while any etl created without DXLogger is fine. I can use GPUView without the DXLogger but I really need the GPU performance data as well.

Both computers have the same OS (vista x64) and same GPU (nvidia QuadroFX3800). The server is a Supermicro machine with a Nehalem CPU.

Any help will be appreciated.

Shai.

Hello Shai, Unfortunately, at this point, I am unable to repro your scenario here. If I had the etl file, I might be able to debug and see what’s causing GPUView crash. Can you share it on a public server that I can get access too?

Yet, sense you’ve been in the log.cmd file, you’ll notice that the log.cmd file has attributes when starting the DXLogger. For instance, the min version is “%TRACE_DX%:0x9” and the light version is “%TRACE_DX%:0x2f”. These flags indicate different groupings of events logged to the etl file. Does the problem occur with both the min and normal logging levels?  (ie, 0x9 and 0x2f)

Can you tell me more about this server machine? I would like to find that specific version to generate a trace file on.

Thank you.

Thank you very much for the reply (I totally forgot about this post). My problem still exists and it's very important for me to find a solution, since GPUView is crucial for the analysis of my system's performance. In the meantime I encountered this problem also on a completely different serverm which uses an AMD CPU.

In this link you can find an etl file created using log light with DX logger (I think it's also with stackwalk, but the problem happens also without stackwalk). Trying to open this file on any computer crashes GPUView. Capturing the same log on the same server without DXLogger created a valid etl file.

Thanks for your help,

Shai.

http://www.mediafire.com/?136zf6juyyjbf45

Hello,

Anyone got a solution? I got same probem here, the logging seems to be fine, but I am not able to open the merged.etl, but I can open kernel.etl

Thanks

I'm still stuck with this as well. No solution.

Even worse, I moved to a 24 core server, and now I can't open the etl at all, even without DX. If anyone knows a workaround for this pleeeease let me know.

Hi,

just to make sure one detail around this.

Did you use the latest version 4.8 from xperfvierwer ?

One additional point:
What is the result if you try to dump the etl --> e.g. forward results in *.txt or *.cvs ?
Can xperf finish this task or also broken ?

BR

I was having this same problem on a Z600 (dual quad core Nehalem machine w/hyperthreading, 16 "cores" in all).

As a workaround, disabling hyperthreading in the BIOS (bringing it down to 8 cores) fixed it.  I've heard from coworkers that disabling cores in the BIOS works too, so perhaps it's just a display issue with >8 core traces.

Hi,

question about your Z600 machine.

Did you get the same result if you reduce the numbers of used cpu with msconfig as well ?
Or works only by BIOS. Because I'm nor sure if all BIOS version have this option available.

Thx

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

I know this is an old thread, but im wondering if anyone has fixed this problem?

I am having the same kind of issue running Windows 7 64 bit

Dxlogger when running with the kernel loggers (producing Dx.etl and kernel.etl) seems to be, either directly or indirectly, what causes GPUView to crash. Though Xperf completes the merge everytime with any combination of etl files (w/ both Dx.etl and kernel or one at a time), so im not sure its xperf(unless there is a conflict somewhere). If i run log.cmd with either of those two ETL files removed, GPUView loads fine, although incomplete. If I do somehow manage to get both files to work together, finally, which does happen, eventually when i stress my system with more DX apps, the same problems crops up again.

The problem appears to be associated with dxetw.dll and it caused a 0xc0000005 exception, which its probably trying to dereference a null value (maybe 4G of memory isn't enough?). Though im skeptical of lack of memory as this can happen with little merge.etl files too (23k-100k), and both free space, and available space is in plenty supply.

So has anyone found a solution? Disabling hyperthreading, for me, isn't a problem because I have no hyperthreading as im using an i5-3570k which has no HT anyways. Unless it thinks that the Ivy bridges do have it, or is tricked into thinking that. But i dont know how to tell.

• Edited by MSUser68 Saturday, January 18, 2014 8:20 PM
• Proposed as answer by GPUView Support Monday, January 20, 2014 7:11 PM

Hi MSUser68,

I would love to try to repro this in-house. Are you willing to share the ETL file that's crashing GPUView? If so, where can I find it?

Thanks,

Dave

Here's a crashing etl file:

http://people.mozilla.org/~jmuizelaar/Merged.zip