BSOD with various error messages

[AFKabi]

So I bought a new computer about... 2-3 weeks ago, and while its been performing really well, once in a while I get random BSOD:

First I had some happening when I left my computer on for long periods of time, every time, would get 1-2 of the same errors:
system error exception and memory management

I did windows updates and whanot

Then I got: IRQL NOT LESS OR EQUAL

And now I got another memory management....

I have no idea how to look at the dumps to look for what is wrong, and what can be firing them, since I don't get them usually when I'm using the computer, and usually not doing anything stressful... IN fact decided to do a quick stress test with prime95 (only one I know) and after 2 minutes fo 100% and 12gb of my 16gb being used by it... it was just fine.

Oh and my memories are the 1866 (though my mother is limited at 1600, I don't think I touched the bios)

Ram: 1866 Mhz Kingston Hyperx Fury
CPU: I5 4690k
Mother: Gigabyte B85-hd3

 

[Tradesman1]

What's the DRAM running at? What data rate and timings, can find them in CPU-Z (free app, in the memory tab

 

[AFKabi]

What's the DRAM running at? What data rate and timings, can find them in CPU-Z (free app, in the memory tab

http://puu.sh/k3Vzc/5d427313be.png

 

[AFKabi]

Hello, I was told the dmp files could help, I found 4 in the minidump folder:

http://puu.sh/k4Npt/e3d50e1c39.rar

Also saw someone asking for this from a different thread:

http://puu.sh/k4OCM/86db8d8c4b.png

 

[Tradesman1]

Try changing the CR (Command rate) from 1T to 2T

 

[AFKabi]

Is that done in the BIOS?

 

[Tradesman1]

Yes

 

[AFKabi]

Thank you for your time!

So I went into the bios, everything was set on Auto by default.

Voltage was 1.5 by default (I remember people talking in other threads about this error about it)
Speed was set to 1600 by default (Mothers cap)
And I found what I assumed was the thing you wanted me to change which was the command rate from "1" to "2" (had to switch to manual)
Only reason I'm not sure if it's what you told me to change is because in the brackets it said crdt? instead of CR

It seems reflected on this: http://puu.sh/k503p/b992ae81ca.png

I will keep it this way for now, see if I get another error or something.

PD: Would you mind telling me what this does? Thanks!

 

[Tradesman1]

Basically the time it takes between when a chips is selected and when it can take a command, 1T or 1N can often be too 'tight' for want of a better word for the DRAM to be stable without extensive other timing and voltage changes - even then it still might be stable. Most DRAM runs at 2T

 

[johnbl]

if this does not fix the issue, change the memory dump from minidump to a kernel memory dump.
https://www.sophos.com/en-us/support/knowledgebase/111474.aspx

then start cmd.exe as an admin, then run
verifier.exe /standard /all
reboot your system, wait for the next bugcheck, then copy up the file c:\windows\memory.dmp
to a server and post a link.
then use verifier.exe /reset to turn off the verifier.


the actual error in the memory dump was caused by a driver releasing the same virutual memory twice, this caused a counter to drop below zero. This can be a memory error, or a actual bug in a driver. (first call by the driver would be ok, the second call would cause a bugcheck because it no longer owns the memory location)
if it is a bug in a driver, verifier will call a bugcheck and name the driver.
if it does not find a driver at least it will save the debug info to allow tracking of the memory tag that was released which will indicate which driver used the memory before the bugcheck.


the 1T and 2T refer to the number of clock ticks required to setup and hold the electronics timing signals before the signals are considered stable (voltages level ranges are converted to 1's and zero). When machines are overclocked you might find that 1 clock tick is just not enough time to get the signals stable. Also, some memory just requires 2 clock ticks to set up commands. Often it will depend on the slot that the memory module is inserted into. more time is required the further the slot is from the CPU.

 

[AFKabi]

Basically the time it takes between when a chips is selected and when it can take a command, 1T or 1N can often be too 'tight' for want of a better word for the DRAM to be stable without extensive other timing and voltage changes - even then it still might be stable. Most DRAM runs at 2T

This did not fix the issue, I decided to leave it on all night to test, and I got another BSOD IRQL NOT LESS OF EQUAL:

Dump: http://puu.sh/k6kyS/0769c411d4.rar

Will try johnbl suggestion now (also you said kernel, but linked to enabling complete)

 

[AFKabi]

if this does not fix the issue, change the memory dump from minidump to a kernel memory dump.
https://www.sophos.com/en-us/support/knowledgebase/111474.aspx

then start cmd.exe as an admin, then run
verifier.exe /standard /all
reboot your system, wait for the next bugcheck, then copy up the file c:\windows\memory.dmp
to a server and post a link.
then use verifier.exe /reset to turn off the verifier.


the actual error in the memory dump was caused by a driver releasing the same virutual memory twice, this caused a counter to drop below zero. This can be a memory error, or a actual bug in a driver. (first call by the driver would be ok, the second call would cause a bugcheck because it no longer owns the memory location)
if it is a bug in a driver, verifier will call a bugcheck and name the driver.
if it does not find a driver at least it will save the debug info to allow tracking of the memory tag that was released which will indicate which driver used the memory before the bugcheck.


the 1T and 2T refer to the number of clock ticks required to setup and hold the electronics timing signals before the signals are considered stable (voltages level ranges are converted to 1's and zero). When machines are overclocked you might find that 1 clock tick is just not enough time to get the signals stable. Also, some memory just requires 2 clock ticks to set up commands. Often it will depend on the slot that the memory module is inserted into. more time is required the further the slot is from the CPU.

I don't know what the starting change was supposed to acomplish, the command one, but I started getting BSOD nonstop from the ndis.sys saying IRQL NOT LESS OR EQUAL.

DUMP of this (I changed the dump that was in place before for a different name so I could issolate this one, plus it was like a 1gb dump) http://puu.sh/k6lKh/5bdd2a30ce.rar
(Am I even supposed to upload them like this, or do I need to do something with this and then upload)

Also found that my SM Bus Controllers was not being detected, but I just solved with this:
http://www.intel.com/support/chipsets/inf/sb/CS-013541.htm

 

[johnbl]

in your case the file that bugchecked was
VBoxNetLwf.sys


\SystemRoot\system32\DRIVERS\VBoxNetLwf.sys Thu Aug 13 09:24:19 2015

it looks like it passed a bad memory address to ndis.sys
your network driver looks like:
Realtek RTL8168D/8111D Family PCI-E Gigabit Ethernet NIC
look here for a update (2015/8/24):
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false
\SystemRoot\system32\DRIVERS\Rt64win7.sys Mon Mar 17 19:27:09 2014


--------
starting cmd.exe as an admin and running the verifier command sets internal debug flags that forces window to do extra driver checking and tells it to bugcheck the system if it finds problems, the bugcheck will name the driver in the memory dump file.

setting a kernel dump causes extra debugging info to be stored in c:\windows\memory.dmp file, it includes extra internal error logs and memory tracking info and more info on your drivers.

note: if you turn on verifier you have to turn it off when you are done or your machine will run slower until you do.
to turn it off you start cmd.exe as an admin then run the command
verifier.exe /reset

-------------
if you get a memory dump you can put it on a server like microsoft onedrive, mark the file as public and post a link.
if your bughceck was in NDIS then the problem will be caused by the Network driver and you will want to get a updated driver. (unless it was a random driver corruption caused by bad memory or BIOS memory settings)

the driver can be any wired or wireless network driver. I can not tell you which one you have without looking at your memory dump. The best place to get a update will be from your motherboard vendors website.
There are special cases if you have a USB wireless adapter, these require more work to get the updates)

if this does not fix the issue, change the memory dump from minidump to a kernel memory dump.
https://www.sophos.com/en-us/support/knowledgebase/111474.aspx

then start cmd.exe as an admin, then run
verifier.exe /standard /all
reboot your system, wait for the next bugcheck, then copy up the file c:\windows\memory.dmp
to a server and post a link.
then use verifier.exe /reset to turn off the verifier.


the actual error in the memory dump was caused by a driver releasing the same virutual memory twice, this caused a counter to drop below zero. This can be a memory error, or a actual bug in a driver. (first call by the driver would be ok, the second call would cause a bugcheck because it no longer owns the memory location)
if it is a bug in a driver, verifier will call a bugcheck and name the driver.
if it does not find a driver at least it will save the debug info to allow tracking of the memory tag that was released which will indicate which driver used the memory before the bugcheck.


the 1T and 2T refer to the number of clock ticks required to setup and hold the electronics timing signals before the signals are considered stable (voltages level ranges are converted to 1's and zero). When machines are overclocked you might find that 1 clock tick is just not enough time to get the signals stable. Also, some memory just requires 2 clock ticks to set up commands. Often it will depend on the slot that the memory module is inserted into. more time is required the further the slot is from the CPU.

I don't know what the starting change was supposed to acomplish, the command one, but I started getting BSOD nonstop from the ndis.sys saying IRQL NOT LESS OR EQUAL.

DUMP of this (I changed the dump that was in place before for a different name so I could issolate this one, plus it was like a 1gb dump) http://puu.sh/k6lKh/5bdd2a30ce.rar
(Am I even supposed to upload them like this, or do I need to do something with this and then upload)

Also found that my SM Bus Controllers was not being detected, but I just solved with this:
http://www.intel.com/support/chipsets/inf/sb/CS-013541.htm

 

[AFKabi]

starting cmd.exe as an admin and running the verifier command sets internal debug flags that forces window to do extra driver checking and tells it to bugcheck the system if it finds problems, the bugcheck will name the driver in the memory dump file.

setting a kernel dump causes extra debugging info to be stored in c:\windows\memory.dmp file, it includes extra internal error logs and memory tracking info and more info on your drivers.

note: if you turn on verifier you have to turn it off when you are done or your machine will run slower until you do.
to turn it off you start cmd.exe as an admin then run the command
verifier.exe /reset

-------------
if you get a memory dump you can put it on a server like microsoft onedrive, mark the file as public and post a link.
if your bughceck was in NDIS then the problem will be caused by the Network driver and you will want to get a updated driver. (unless it was a random driver corruption caused by bad memory or BIOS memory settings)

the driver can be any wired or wireless network driver. I can not tell you which one you have without looking at your memory dump. The best place to get a update will be from your motherboard vendors website.
There are special cases if you have a USB wireless adapter, these require more work to get the updates)

if this does not fix the issue, change the memory dump from minidump to a kernel memory dump.
https://www.sophos.com/en-us/support/knowledgebase/111474.aspx

then start cmd.exe as an admin, then run
verifier.exe /standard /all
reboot your system, wait for the next bugcheck, then copy up the file c:\windows\memory.dmp
to a server and post a link.
then use verifier.exe /reset to turn off the verifier.


the actual error in the memory dump was caused by a driver releasing the same virutual memory twice, this caused a counter to drop below zero. This can be a memory error, or a actual bug in a driver. (first call by the driver would be ok, the second call would cause a bugcheck because it no longer owns the memory location)
if it is a bug in a driver, verifier will call a bugcheck and name the driver.
if it does not find a driver at least it will save the debug info to allow tracking of the memory tag that was released which will indicate which driver used the memory before the bugcheck.


the 1T and 2T refer to the number of clock ticks required to setup and hold the electronics timing signals before the signals are considered stable (voltages level ranges are converted to 1's and zero). When machines are overclocked you might find that 1 clock tick is just not enough time to get the signals stable. Also, some memory just requires 2 clock ticks to set up commands. Often it will depend on the slot that the memory module is inserted into. more time is required the further the slot is from the CPU.

I don't know what the starting change was supposed to acomplish, the command one, but I started getting BSOD nonstop from the ndis.sys saying IRQL NOT LESS OR EQUAL.

DUMP of this (I changed the dump that was in place before for a different name so I could issolate this one, plus it was like a 1gb dump) http://puu.sh/k6lKh/5bdd2a30ce.rar
(Am I even supposed to upload them like this, or do I need to do something with this and then upload)

Also found that my SM Bus Controllers was not being detected, but I just solved with this:
http://www.intel.com/support/chipsets/inf/sb/CS-013541.htm

I uploaded the DUMP file in my previous message as a .DMP in a rar file (first link), I will look into the other things you mention.

However:


WHen I first installed my computer it wouldn't connect to internet, I had to download the drivers in my phone from the official site, and then it worked. I dunno why that happened.

 

[johnbl]

looks like you have two network cards in your machine, and the error was caused because the card #2 was attempting to start and had to divert data because of a return code of: NDIS_STATUS_MEDIA_DISCONNECTED

basically cable not plugged in I would think.


guess it could also be a issue with TunnelBear Adapter V9
but try the network driver update first.
--------
got it, added a note to the previous response. Update the network driver as a first attempt as a fix.

starting cmd.exe as an admin and running the verifier command sets internal debug flags that forces window to do extra driver checking and tells it to bugcheck the system if it finds problems, the bugcheck will name the driver in the memory dump file.

setting a kernel dump causes extra debugging info to be stored in c:\windows\memory.dmp file, it includes extra internal error logs and memory tracking info and more info on your drivers.

note: if you turn on verifier you have to turn it off when you are done or your machine will run slower until you do.
to turn it off you start cmd.exe as an admin then run the command
verifier.exe /reset

-------------
if you get a memory dump you can put it on a server like microsoft onedrive, mark the file as public and post a link.
if your bughceck was in NDIS then the problem will be caused by the Network driver and you will want to get a updated driver. (unless it was a random driver corruption caused by bad memory or BIOS memory settings)

the driver can be any wired or wireless network driver. I can not tell you which one you have without looking at your memory dump. The best place to get a update will be from your motherboard vendors website.
There are special cases if you have a USB wireless adapter, these require more work to get the updates)

if this does not fix the issue, change the memory dump from minidump to a kernel memory dump.
https://www.sophos.com/en-us/support/knowledgebase/111474.aspx

then start cmd.exe as an admin, then run
verifier.exe /standard /all
reboot your system, wait for the next bugcheck, then copy up the file c:\windows\memory.dmp
to a server and post a link.
then use verifier.exe /reset to turn off the verifier.


the actual error in the memory dump was caused by a driver releasing the same virutual memory twice, this caused a counter to drop below zero. This can be a memory error, or a actual bug in a driver. (first call by the driver would be ok, the second call would cause a bugcheck because it no longer owns the memory location)
if it is a bug in a driver, verifier will call a bugcheck and name the driver.
if it does not find a driver at least it will save the debug info to allow tracking of the memory tag that was released which will indicate which driver used the memory before the bugcheck.


the 1T and 2T refer to the number of clock ticks required to setup and hold the electronics timing signals before the signals are considered stable (voltages level ranges are converted to 1's and zero). When machines are overclocked you might find that 1 clock tick is just not enough time to get the signals stable. Also, some memory just requires 2 clock ticks to set up commands. Often it will depend on the slot that the memory module is inserted into. more time is required the further the slot is from the CPU.

I don't know what the starting change was supposed to acomplish, the command one, but I started getting BSOD nonstop from the ndis.sys saying IRQL NOT LESS OR EQUAL.

DUMP of this (I changed the dump that was in place before for a different name so I could issolate this one, plus it was like a 1gb dump) http://puu.sh/k6lKh/5bdd2a30ce.rar
(Am I even supposed to upload them like this, or do I need to do something with this and then upload)

Also found that my SM Bus Controllers was not being detected, but I just solved with this:
http://www.intel.com/support/chipsets/inf/sb/CS-013541.htm

I uploaded the DUMP file in my previous message as a .DMP in a rar file (first link), I will look into the other things you mention.

However:


WHen I first installed my computer it wouldn't connect to internet, I had to download the drivers in my phone from the official site, and then it worked. I dunno why that happened.

 

[itmoba]

Whilst perusing through the memory dump file, I discovered a few peculiarities contained therewith. I'd like to hear from AFKabi why some of these oddities would surface in this exploration of a sort:

(the uppercase characters in the following statements are copied verbatim from a hexdump)

END_OF_NT_EVALUATION_PERIOD INVALID_REGION_OR_SEGMENT SYSTEM_LICENSE_VIOLATION 
UDFS_FILE_SYSTEM MACHINE_CHECK_EXCEPTION T One or more critical user mode components 
failed to satisfy a health check.

The following is the corresponding text in hex:

45 4E 44 5F 4F 46 5F 4E 54 5F 45 56 41 4C 55 41
54 49 4F 4E 5F 50 45 52 49 4F 44 0D 0A 00 00 00
20 00 00 00 49 4E 56 41 4C 49 44 5F 52 45 47 49
4F 4E 5F 4F 52 5F 53 45 47 4D 45 4E 54 0D 0A 00
20 00 00 00 53 59 53 54 45 4D 5F 4C 49 43 45 4E
53 45 5F 56 49 4F 4C 41 54 49 4F 4E 0D 0A 00 00
18 00 00 00 55 44 46 53 5F 46 49 4C 45 5F 53 59
53 54 45 4D 0D 0A 00 00 20 00 00 00 4D 41 43 48
49 4E 45 5F 43 48 45 43 4B 5F 45 58 43 45 50 54
49 4F 4E 0D 0A 00 00 00 54 00 00 00 4F 6E 65 20
6F 72 20 6D 6F 72 65 20 63 72 69 74 69 63 61 6C
20 75 73 65 72 20 6D 6F 64 65 20 63 6F 6D 70 6F
6E 65 6E 74 73 20 66 61 69 6C 65 64 20 74 6F 20
73 61 74 69 73 66 79 20 61 20 68 65 61 6C 74 68
20 63 68 65 63 6B 2E

The part of concern noted above resides between address blocks 024F:FF74 and 0250:005A of the unarchived contents of the file-name "5bdd2a30ce.rar", which is/was provided in an earlier response. The link to the file should be removed for the user's safety, as it contains private information.

 

[AFKabi]

Whilst perusing through the memory dump file, I discovered a few peculiarities contained therewith. I'd like to hear from AFKabi why some of these oddities would surface in this exploration of a sort:

(the uppercase characters in the following statements are copied verbatim from a hexdump)

END_OF_NT_EVALUATION_PERIOD INVALID_REGION_OR_SEGMENT SYSTEM_LICENSE_VIOLATION 
UDFS_FILE_SYSTEM MACHINE_CHECK_EXCEPTION T One or more critical user mode components 
failed to satisfy a health check.

The following is the corresponding text in hex:

45 4E 44 5F 4F 46 5F 4E 54 5F 45 56 41 4C 55 41
54 49 4F 4E 5F 50 45 52 49 4F 44 0D 0A 00 00 00
20 00 00 00 49 4E 56 41 4C 49 44 5F 52 45 47 49
4F 4E 5F 4F 52 5F 53 45 47 4D 45 4E 54 0D 0A 00
20 00 00 00 53 59 53 54 45 4D 5F 4C 49 43 45 4E
53 45 5F 56 49 4F 4C 41 54 49 4F 4E 0D 0A 00 00
18 00 00 00 55 44 46 53 5F 46 49 4C 45 5F 53 59
53 54 45 4D 0D 0A 00 00 20 00 00 00 4D 41 43 48
49 4E 45 5F 43 48 45 43 4B 5F 45 58 43 45 50 54
49 4F 4E 0D 0A 00 00 00 54 00 00 00 4F 6E 65 20
6F 72 20 6D 6F 72 65 20 63 72 69 74 69 63 61 6C
20 75 73 65 72 20 6D 6F 64 65 20 63 6F 6D 70 6F
6E 65 6E 74 73 20 66 61 69 6C 65 64 20 74 6F 20
73 61 74 69 73 66 79 20 61 20 68 65 61 6C 74 68
20 63 68 65 63 6B 2E

The part of concern noted above resides between address blocks 024F:FF74 and 0250:005A of the unarchived contents of the file-name "5bdd2a30ce.rar", which is/was provided in an earlier response. The link to the file should be removed for the user's safety, as it contains private information.

I really really don't understand what you are talking about 😛 Would you mind explaining what you are saying?

 

[itmoba]

Whilst perusing through the memory dump file, I discovered a few peculiarities contained therewith. I'd like to hear from AFKabi why some of these oddities would surface in this exploration of a sort:

(the uppercase characters in the following statements are copied verbatim from a hexdump)

END_OF_NT_EVALUATION_PERIOD INVALID_REGION_OR_SEGMENT SYSTEM_LICENSE_VIOLATION 
UDFS_FILE_SYSTEM MACHINE_CHECK_EXCEPTION T One or more critical user mode components 
failed to satisfy a health check.

The following is the corresponding text in hex:

45 4E 44 5F 4F 46 5F 4E 54 5F 45 56 41 4C 55 41
54 49 4F 4E 5F 50 45 52 49 4F 44 0D 0A 00 00 00
20 00 00 00 49 4E 56 41 4C 49 44 5F 52 45 47 49
4F 4E 5F 4F 52 5F 53 45 47 4D 45 4E 54 0D 0A 00
20 00 00 00 53 59 53 54 45 4D 5F 4C 49 43 45 4E
53 45 5F 56 49 4F 4C 41 54 49 4F 4E 0D 0A 00 00
18 00 00 00 55 44 46 53 5F 46 49 4C 45 5F 53 59
53 54 45 4D 0D 0A 00 00 20 00 00 00 4D 41 43 48
49 4E 45 5F 43 48 45 43 4B 5F 45 58 43 45 50 54
49 4F 4E 0D 0A 00 00 00 54 00 00 00 4F 6E 65 20
6F 72 20 6D 6F 72 65 20 63 72 69 74 69 63 61 6C
20 75 73 65 72 20 6D 6F 64 65 20 63 6F 6D 70 6F
6E 65 6E 74 73 20 66 61 69 6C 65 64 20 74 6F 20
73 61 74 69 73 66 79 20 61 20 68 65 61 6C 74 68
20 63 68 65 63 6B 2E

The part of concern noted above resides between address blocks 024F:FF74 and 0250:005A of the unarchived contents of the file-name "5bdd2a30ce.rar", which is/was provided in an earlier response. The link to the file should be removed for the user's safety, as it contains private information.

I really really don't understand what you are talking about 😛 Would you mind explaining what you are saying?

Directly from Microsoft: "The END_OF_NT_EVALUATION_PERIOD bug check has a value of 0x00000098. This bug check indicates that the trial period for the Microsoft Windows operating system has ended.... Your installation of the Windows operating system is an evaluation unit with an expiration date. The trial period is over."

See: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559306(v=vs.85).aspx

 

[AFKabi]

Whilst perusing through the memory dump file, I discovered a few peculiarities contained therewith. I'd like to hear from AFKabi why some of these oddities would surface in this exploration of a sort:

(the uppercase characters in the following statements are copied verbatim from a hexdump)

END_OF_NT_EVALUATION_PERIOD INVALID_REGION_OR_SEGMENT SYSTEM_LICENSE_VIOLATION 
UDFS_FILE_SYSTEM MACHINE_CHECK_EXCEPTION T One or more critical user mode components 
failed to satisfy a health check.

The following is the corresponding text in hex:

45 4E 44 5F 4F 46 5F 4E 54 5F 45 56 41 4C 55 41
54 49 4F 4E 5F 50 45 52 49 4F 44 0D 0A 00 00 00
20 00 00 00 49 4E 56 41 4C 49 44 5F 52 45 47 49
4F 4E 5F 4F 52 5F 53 45 47 4D 45 4E 54 0D 0A 00
20 00 00 00 53 59 53 54 45 4D 5F 4C 49 43 45 4E
53 45 5F 56 49 4F 4C 41 54 49 4F 4E 0D 0A 00 00
18 00 00 00 55 44 46 53 5F 46 49 4C 45 5F 53 59
53 54 45 4D 0D 0A 00 00 20 00 00 00 4D 41 43 48
49 4E 45 5F 43 48 45 43 4B 5F 45 58 43 45 50 54
49 4F 4E 0D 0A 00 00 00 54 00 00 00 4F 6E 65 20
6F 72 20 6D 6F 72 65 20 63 72 69 74 69 63 61 6C
20 75 73 65 72 20 6D 6F 64 65 20 63 6F 6D 70 6F
6E 65 6E 74 73 20 66 61 69 6C 65 64 20 74 6F 20
73 61 74 69 73 66 79 20 61 20 68 65 61 6C 74 68
20 63 68 65 63 6B 2E

The part of concern noted above resides between address blocks 024F:FF74 and 0250:005A of the unarchived contents of the file-name "5bdd2a30ce.rar", which is/was provided in an earlier response. The link to the file should be removed for the user's safety, as it contains private information.

I really really don't understand what you are talking about 😛 Would you mind explaining what you are saying?

Directly from Microsoft: "The END_OF_NT_EVALUATION_PERIOD bug check has a value of 0x00000098. This bug check indicates that the trial period for the Microsoft Windows operating system has ended.... Your installation of the Windows operating system is an evaluation unit with an expiration date. The trial period is over."

See: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559306(v=vs.85).aspx

Ok, thanks, that is weird, I will contact the store that sold me windows, to see why it says its trial 🙁... One problem at a time though, I want to see if my ram is broken too.

 

[itmoba]

In the future, please don't upload the MEMORY.DMP file and post it for everyone to see. You've given away a lot of private information in doing so. The mini-dumps are perfectly fine to share, though they too contain personal information. No one here is liable for your mistake. I hope that no one uses the data for any nefarious purposes.

 

[AFKabi]

In the future, please don't upload the MEMORY.DMP file and post it for everyone to see. You've given away a lot of private information in doing so. The mini-dumps are perfectly fine to share, though they too contain personal information. No one here is liable for your mistake. I hope that no one uses the data for any nefarious purposes.

Thank you I'm not very good with computers I just play games on this, I been using google a lot to get around and help you guys with my problems. I deleted the files when you said it had critical information, was scared, I dunno what critical means.... Don't want personal info all over the place

 

[itmoba]

To clarify, private information includes, email and other user accounts, passwords, serial keys and license information, software utilization information (e.g., running a torrent client that says it's acquiring pirated media), and other things which could potentially implicate you in a crime (implication is not conviction, though implication can lead to conviction).

 

[johnbl]

A expired trial of windows would explain why the network drivers did seem to be disabled.


-------
a kernel memory dump only contains the info used by the kernel, not the data allocated to user mode programs or unallocated memory.
It does contain the stack of all the device drivers, and many internal logs that help determine the cause of problems.

sure, someone can poke around and get your IP address, and the name of your machine, and the name you logged into the system with.
The name and dates of the drivers. Some problems can only be debugged with a kernel dump.

As to seeing unlicensed copies of software, it depends on where you are located in many countries it simply is not a crime to ignore a license agreement or modify code. Here in the USA it is against copyright acts. Other countries, you can get a copy of windows, make copies and sell them without breaking local laws.

running torrent client is also not unlawful in the USA.

It would be silly to worry about someone getting your IP address from a memory dump, when tom's hardware will have could have your IP address thru your internet connection, the server you put your memory dump on would have your ip address also. If you worry about the content of your email, it is not in the kernel memory dump. (no user mode data)

if you worry about it, delete your memory dump after it is looked at, or what? don't figure out what is wrong with your machine?

even to imply that you have an expired copy of some software is silly, the hex dump shows that the string is in the BINARY.
The string will be in the binary BEFORE and the software expires. It was put in the BINARY when the binary was compiled before you installed the software.
You should expect it to be in the binary.