crazytok

Mars 21, 2009

Ett 32 bitars operativsystem kan inte använda mer än drygt 3gb minne.

Är det så?

Varför i he****e är det så då, mer än 3Gb i RAM är väl absolut ingen ovanligt?? Och det finns inget man kan göra för att få ett 32bit OS att utnyttja mer?

Eller är det helt enkelt 64bit som gäller då? Vad är egentligen skillnaden mellan att köra 32bit och 64bit OS, vad finns det för FÖR och NACKDELAR med detta?

Tack för hjälpen!

Mars 20, 2009

Ok, har köpt 2st nya minnen nu. 2x2048Mb minnen... Har monterat i dessa samt det ena minnen från innan som var på 1024Mb.

Har kört Memtest86+ och kontrollerat att allt funkar som det skall och det gör det...

Dvs sammanlagt har jag nu 5120Mb i ram.

Varav 512Mb används till det integrerade grafikkortet.

Då skall det alltså vara 4608Mb kvar, rätt?

När jag sedan startat windows xp pro 32bit som jag kör, och sedan koller under egenskaper av den här datorn registrerar den bara 2,75Gb Ram. Varför detta?

Notera att jag vid uppstart får Bios att registrera det rätta värdet av 5120Mb ram minus 512 som upptas utav grafikkortet.

Vid användande av System Information for Windows får jag reda på följande för RAM:

Property Value

Memory Summary

Location System board or motherboard

Maximum Capacity 2048 MBytes

Memory Slots 4

Error Correction None

Use System memory

Maximum Memory Module Size 4096 MBytes

Device Locator A0

Bank Locator Bank0/1

Part Number None

Serial Number None

Capacity 2048 MBytes

Speed 800 MHz

Data Width 64 bits

Name None

Form Factor DIMM

Total Width 64 bits

Device Locator A1

Bank Locator Bank2/3

Part Number None

Serial Number None

Capacity 2048 MBytes

Speed 800 MHz

Data Width 64 bits

Name None

Form Factor DIMM

Total Width 64 bits

Device Locator A2

Bank Locator Bank4/5

Part Number None

Serial Number None

Capacity 1024 MBytes

Speed 800 MHz

Data Width 64 bits

Name None

Form Factor DIMM

Total Width 64 bits

Warning! Accuracy of DMI data cannot be guaranteed

och följande för Moderkortet:

Property Value

Manufacturer Gigabyte Technology Co., Ltd.

Model GA-MA78G-DS3H

Version x.x

Serial Number Tue Jan 01 00:02:27 2008

Chipset Vendor Advanced Micro Devices (AMD)

South Bridge SB700 LPC host controller

CPU AMD Athlon 64 X2 5600+

Cpu Socket Socket AM2 [socket M2]

Processor Upgrade

Max CPU Speed 3000 MHz

System Slots 7 PCI, 1 AGP

Memory Summary

Location System board or motherboard

Maximum Capacity 2048 MBytes

Memory Slots 4

Error Correction None

Use System memory

Maximum Memory Module Size 4096 MBytes

Warning! Accuracy of DMI data cannot be guaranteed

Varför säger den Maximum Capacity 2048Mb när Memory Module Size säger 4096Mb?

Mars 18, 2009

Ok, fick väl inte ut så mycket mer utav Extended Memory Test egentligen... Men det verkar ju vara just Minnesbank 2 som strular när Minnesmodul A sitter i. Finns det någon förklaring varför det strular med just bank2 och med endast ett utav minnena på denna plats? Den funkar ju i bank1!

Om jag köper nya minnen, kommer det verkligen att fungera då. Det är inte någon konflikt mellan bankerna och minnena som går att justera på något vis?

Mars 17, 2009

Ok, har gjort lite snabbtester utav minnet med hjälp av Windows Memory Diagnostic nu och kom fram till följande:

Jag har två st minnesmoduler på vardera 1024Mb, jag kallar dom "A" och "B"...

Modul A passerar standard testet i Minnesbank 1 & 2 utan problem.

Modul B passerar standard testet i Minnesbank 1 utan problem, dock ej i Minnesbank 2 där den får Failure på allt.

Med både Modul A och B inkopplade oavsett om Modul B sitter i Minnesbank 1 eller 2 så blir det failure...

Tycker det är märkligt att Modul B fungerar i MB1 och inte i MB2? Någon som har en rimligt förklaring till detta?

För övrigt, ni som svarade att det förmodligen var ett Minnesrelaterat fel. Hur avläste ni detta utifrån den Minidump informationen jag gav er? Vill gärna lära mig lite så man kanske kan felsöka själv i framtiden...

Jag håller just nu på att göra ett Extended Memory Test, antar att det tar en stund så det får jag rapportera om imorgon.

Men jag verkar ju vara på rätt väg iaf, och det är tack vare er!!!

SÅ ETT STORT TACK!!!

Mars 17, 2009

Tack för er hjälp!

Skall genast testa detta och se om jag kan komma fram till något...

Om det visar sig att minnesmodulerna är hela då, dvs om det kanske är en drivrutin som är fel. Kan man på något sätt komma fram till vilken drivrutin det är som kan vara boven i dramat? Är det Memory.dmp som kan komma till hjälp då? Isf kan jag posta den nästa gång jag får blåskärm...

Men skall som sagt testa minnesmodulerna först, återkommer!

Mars 16, 2009

Ok, nu behöver jag experthjälp.

Har haft problem med att min dator startar om med jämna mellanrum och då ofta med blåskärm och meddelandet IRQL_NOT_LESS_OR_EQUAL. Denna dator står på dygnet runt och ofta startar den om mitt i natten vilket gör att jag då inte vet om det alltid blir blåskärm.

Datorn är relativt ny, har köpt delar själv och byggt ihop den. Har haft den i ca:6månader och den har fungerat kanon fram till ca:1månad sedan...

Jag har testat att köra Windbg och öppnat en av filerna som ligger i Minidump mappen. (vad är det för skillnad på dessa och Memory.dmp?)

Dock förstår jag ju inte mycket utav den information jag får fram och behöver därför lite expertis hjälp, eller en vägledning till var jag kan få hjälp med att åtgärda mitt problem.

Eftersom jag har flera filer i Minidump mappen bifogar jag här dom senaste två dump filerna och ser om det kan hjälpa.

Microsoft ® Windows Debugger Version 6.11.0001.404 X86

Loading Dump File [C:\WINDOWS\Minidump\Mini031509-02.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\WINDOWS\Symbols*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible

Product: WinNt

Built by: 2600.xpsp_sp3_gdr.080814-1236

Machine Name:

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720

Debug session time: Sun Mar 15 20:45:39.828 2009 (GMT+1)

System Uptime: 0 days 3:40:25.077

Loading Kernel Symbols

...............................................................

................................................................

...............

Loading User Symbols

Loading unloaded module list

.........

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {91aaf008, 2, 1, 8052390d}

Probably caused by : memory_corruption ( nt!MiReleasePageFileSpace+55 )

Followup: MachineOwner

---------

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 91aaf008, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000001, bitfield :

bit 0 : value 0 = read operation, 1 = write operation

bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)

Arg4: 8052390d, address which referenced memory

Debugging Details:

------------------

WRITE_ADDRESS: 91aaf008

CURRENT_IRQL: 2

FAULTING_IP:

nt!MiReleasePageFileSpace+55

8052390d 213e and dword ptr [esi],edi

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: a580aac0 -- (.trap 0xffffffffa580aac0)

ErrCode = 00000002

eax=8a2b32f0 ebx=c000b020 ecx=00000000 edx=00000000 esi=91aaf008 edi=fffffffe

eip=8052390d esp=a580ab34 ebp=a580ab44 iopl=0 nv up ei pl zr na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246

nt!MiReleasePageFileSpace+0x55:

8052390d 213e and dword ptr [esi],edi ds:0023:91aaf008=????????

Resetting default scope

LAST_CONTROL_TRANSFER: from 8052390d to 805446f0

STACK_TEXT:

a580aac0 8052390d badb0d00 00000000 bf805500 nt!KiTrap0E+0x238

a580ab44 80523e44 00000000 42000000 01604000 nt!MiReleasePageFileSpace+0x55

a580ab7c 80523fb8 c000b020 01604000 00000000 nt!MiDeletePte+0x4a2

a580ac44 8051a1dd e1a7db20 018b3fff 00000000 nt!MiDeleteVirtualAddresses+0x164

a580acf4 805b2d79 87ca1598 8a146fc8 a580ad64 nt!MiRemoveMappedView+0x237

a580ad38 805b2e68 8a2db858 87cb2e48 00000000 nt!MiUnmapViewOfSection+0x12b

a580ad54 8054162c ffffffff 87ca1598 00cef4a0 nt!NtUnmapViewOfSection+0x54

a580ad54 7c90e4f4 ffffffff 87ca1598 00cef4a0 nt!KiFastCallEntry+0xfc

WARNING: Frame IP not in any known module. Following frames may be wrong.

00cef4a0 00000000 00000000 00000000 00000000 0x7c90e4f4

STACK_COMMAND: kb

FOLLOWUP_IP:

nt!MiReleasePageFileSpace+55

8052390d 213e and dword ptr [esi],edi

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!MiReleasePageFileSpace+55

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 48a3fbd9

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: 0xA_nt!MiReleasePageFileSpace+55

BUCKET_ID: 0xA_nt!MiReleasePageFileSpace+55

Followup: MachineOwner

---------

Microsoft ® Windows Debugger Version 6.11.0001.404 X86

Loading Dump File [C:\WINDOWS\Minidump\Mini031509-01.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\WINDOWS\Symbols*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible

Product: WinNt

Built by: 2600.xpsp_sp3_gdr.080814-1236

Machine Name:

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720

Debug session time: Sun Mar 15 16:46:08.223 2009 (GMT+1)

System Uptime: 0 days 14:45:01.972

Loading Kernel Symbols

...............................................................

................................................................

..............

Loading User Symbols

Loading unloaded module list

..........

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {c7ddf4f0, 2, 0, 8051bb93}

Probably caused by : memory_corruption ( nt!MmCopyToCachedPage+1b1 )

Followup: MachineOwner

---------

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: c7ddf4f0, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, bitfield :

bit 0 : value 0 = read operation, 1 = write operation

bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)

Arg4: 8051bb93, address which referenced memory

Debugging Details:

------------------

READ_ADDRESS: c7ddf4f0

CURRENT_IRQL: 2

FAULTING_IP:

nt!MmCopyToCachedPage+1b1

8051bb93 8b00 mov eax,dword ptr [eax]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: a4cda8cc -- (.trap 0xffffffffa4cda8cc)

ErrCode = 00000000

eax=c7ddf4f0 ebx=d5886000 ecx=00000000 edx=00000000 esi=e261c220 edi=03000000

eip=8051bb93 esp=a4cda940 ebp=a4cdaa40 iopl=0 nv up ei pl zr na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246

nt!MmCopyToCachedPage+0x1b1:

8051bb93 8b00 mov eax,dword ptr [eax] ds:0023:c7ddf4f0=????????

Resetting default scope

LAST_CONTROL_TRANSFER: from 8051bb93 to 805446f0

STACK_TEXT:

a4cda8cc 8051bb93 badb0d00 00000000 a4cda8ec nt!KiTrap0E+0x238

a4cdaa40 804e39f9 c9f44000 0f6dd650 00000000 nt!MmCopyToCachedPage+0x1b1

a4cdaad0 804e17ee 89587008 0f6dd650 a4cdab04 nt!CcMapAndCopy+0x1af

a4cdab54 b9d5c846 87dd12a8 00d44000 00001000 nt!CcFastCopyWrite+0x230

a4cdabbc b9dc8a27 87dd12a8 87c11fa0 00001000 Ntfs!NtfsCopyWriteA+0x23d

a4cdabf0 b9dd6018 87dd12a8 87c11fa0 00001000 sr!SrFastIoWrite+0x77

a4cdac24 b9dd61e4 00000004 00000000 87c11f98 fltmgr!FltpPerformFastIoCall+0x230

a4cdac50 b9de1c38 00cdac70 00000001 00000000 fltmgr!FltpPassThroughFastIo+0x78

a4cdac90 8057d1fd 87dd12a8 a4cdacd4 00001000 fltmgr!FltpFastIoWrite+0x148

a4cdad38 8054162c 00000398 00000000 00000000 nt!NtWriteFile+0x30b

a4cdad38 7c90e4f4 00000398 00000000 00000000 nt!KiFastCallEntry+0xfc

WARNING: Frame IP not in any known module. Following frames may be wrong.

0012f050 00000000 00000000 00000000 00000000 0x7c90e4f4

STACK_COMMAND: kb

FOLLOWUP_IP:

nt!MmCopyToCachedPage+1b1

8051bb93 8b00 mov eax,dword ptr [eax]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!MmCopyToCachedPage+1b1

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 48a3fbd9

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: 0xA_nt!MmCopyToCachedPage+1b1

BUCKET_ID: 0xA_nt!MmCopyToCachedPage+1b1