Jump to content
AIDA64 Discussion Forum

Squall Leonhart

Members
  • Content Count

    349
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Squall Leonhart

  1. nvidia are still claiming no repro, so i think they are missing a particular configuration requirement to bring it out. They might need one of our cfg files and sensor panels or whatever
  2. This issue is occurring in the nvidia kernel driver, your isn't hasn't been fixed its just gone into a really random occurance cycle. A process cannot cause a bsod, a driver would have been flagged that was loaded by the process but it might be wrong too (as different utilities can be more or even less correct about analysing dump files with the symbols available. 397.55 or earlier are not affected by this, so if you're on 397.64 or .93, theres your culprit.
  3. Gigabyte are using a nasty mutex access, as usual :\
  4. Driver feedback to https://surveys.nvidia.com/index.jsp?pi=6e7ea6bb4a02641fa8f07694a40f8ac6 dump file to driverfeedback@nvidia.com
  5. you are mixing system management utilities.
  6. dump file must go to nvidia and feedback provided with system details, this is an nvidia driver bug. PS: it comes up as being in ntkrnlmp.exe here, all changes based on the application scanning the dump.
  7. Turn hpet on, This is a platform bug where timers slowdown after resuming from sleep.
  8. This topic involved a crash in the application that occured when it was left on that page of aida64, this has been fixed for a long long time now. PS: Don't turn off the page file, windows can't do some things with one turned off, such as allocate large virtual blocks (whether it intends to fill them or not). Set a Min/Max pagefile instead.
  9. Drive type and model would be agood idea too ;), as well as the ahci driver in use.
  10. I believe the nvidia kernel mode driver is suffering a double free or use after free which is brought on via applications using nvapi, thats why the faulting process is one which accesses the card using this api. windows will often say ntoskernl or ntkrnlmp because of an imprecise timing issue in the exception handler, in my case its pointing at X64_0x1E_nt!KiDispatchException+1c7 which is definitely not the actual fault lol.
  11. not nicehash itself, the claymore binary and a few others have nvapi interaction to monitor card thermals and disable p2 cuda.
  12. i can't say i ever had issues with 391.35, it might be just your unique mining configuration in that case Xixou,
  13. But now Driver is corrupting memory, I've had bsods with aida64 and gpu-shark so far, others have with precision and msi ab Fiery, does AIDA64 refresh sensors when running in the tray but no output panels or lcd's are set up? asking because if nvidia tries to repro the bsod issue on aida64 they'll have to do it on the GPU info or Sensors if the refreshing is paused when the window isn't active.
  14. Blast from the past, but i just found an nvidia txt file covering this issue XD http://download.nvidia.com/open-gpu-doc/gk104-disable-underflow-reporting/1/gk104-disable-underflow-reporting.txt
  15. I've just done some file drop trickery to get aida64/gpuz to use an older nvapi to stop the leaks, same with the nvidia containers
  16. r397 fixes one thing and breaks everything else on windows 7, any sensoring app you open leaks GDI objects Aida64 included (as of 397.55)
  17. Follow up post since others are reading this "Commit Size" is titled "Page File" in windows XP/9x and certain utilities made by a Unwinder, but it does not reflect the amount of of actual on-disk page file in use.
  18. ooo.... so the lack of an actual register is why my 10-10-10-27 ram shows up as 8-10-10-27 in CPU-Z/PC Wizard and 11-10-10-27 in AIDA64/HWInfo after resume from S3 It's pulling a last known value from somewhere in different ways.
×
×
  • Create New...