Does anyone know what the "NK.EXE" process is? [Archive]

View Full Version : Does anyone know what the "NK.EXE" process is?

Darkeyce

11th March 2007, 06:29 PM

I'm running WM6 w/spb mobile shell and trying to use SPB Backup, but for the last two days i've been seeing a log message about someting called the "NK.EXE" process blocking a read on "windows/compimeh.0409.dat"

Any help appreciated.
Thanks.

MikeChannon

11th March 2007, 08:50 PM

Darkeyce

11th March 2007, 10:34 PM

Ah...thanks...I wonder if i can exclude that...:cool:

mviana

26th March 2007, 03:04 AM

I too am having the same problem. Can this be fixed? Am I missing something? Am I always going to have this problem now that I am running WMBE 1.2? Is it a big deal? Is there a way to fix it? I would like SPB Backup to work without any problems.

Many thanks for the answers to my questions.

Thanks

Marc

Maggy

11th October 2007, 01:56 PM

It's no big deal.
compimeh.0409.dat is data only meant to be written/read by the operating system

Olipro

11th October 2007, 02:05 PM

NK.EXE is a required kernel system process.

Mike

actually... it's THE kernel

Maggy

11th October 2007, 09:31 PM

actually... it's THE kernel

Stripping the peach:
the skin is not the kernel, neither is the fruity juicy flesh. Most people would call the stone the kernel, but is it? No, inside the stone is a nut. Is that the kernel? or is that tiny little baby plant inside the nut the actual kernel?...

MikeChannon

11th October 2007, 09:49 PM

Stripping the peach:
the skin is not the kernel, neither is the fruity juicy flesh. Most people would call the stone the kernel, but is it? No, inside the stone is a nut. Is that the kernel? or is that tiny little baby plant inside the nut the actual kernel?...

I am pink therefore I'm spam.

But seriously when you find the value of X you will have the answer to your kernel conundrum:

http://i134.photobucket.com/albums/q109/mikechannon/X2.jpg

It's all very simple really:)

Mike

cmonex

12th October 2007, 02:11 AM

Maggy

12th October 2007, 12:17 PM

Okay, okay, I'll take your word for it ;-)

Back to serious: Do you know if NK.EXE is very different for different devices and if it changed a lot over the years?

cmonex

16th October 2007, 03:03 PM

Okay, okay, I'll take your word for it ;-)

Back to serious: Do you know if NK.EXE is very different for different devices and if it changed a lot over the years?

yes...

every CE version since CE 1.0 has seen changes in the kernel... sometimes very big changes...

and yes it is device specific because the hardware abstraction layer (which is called OAL in our case) is linked into the same exe as the kernel, i.e. NK.exe.

this will change in CE6 (no, WM6 is not CE6!!).

....why did you ask about this ?

Maggy

16th October 2007, 04:47 PM

cmonex

21st October 2007, 04:56 AM

Because I own a Himalaya and a Backpack (CF slot, extra battery and VGA/composit output for Hima). Lots of Hima users who upgraded to WM5 or WM6 have their Backpacks laying in a drawer unused because there are no working drivers. I guess I found out why they refuse to work, the cause is IMHO in NK.EXE. I'm trying to gather courage to dive deep into disassembling it...

sorry for slow reply.

if you need help with kernel disassembly let me know :)

also, do you know asm? that'll be needed a lot. and reading the C sources as well.

i've had some fun before with nk.exe..

but why do you think the cause for your problem is nk.exe?

can you tell me more details?

Maggy

22nd October 2007, 03:25 PM

Thanks for the kind offer. I've done some x86 ASM programming in the late 80's, early 90's, so no, I'm not an experienced XScale ASM programmer and much less capable of of porting bits and pieces of drivers and kernel from WM2003 to WM6. But I'm willing to learn and there are many backpack owners who currently can't use it for anything else than for VGA/composit output.

BTW I've read lots of C sources over the years, some I do understand at first sight, some I'm totally unable to read. But how is C related to this problem?

All that's known about Himalaya ASIC5 as far as I can find it:
http://wiki.xda-developers.com/index.php?pagename=HimalayaASIC5
This chip handles PCMCIA so it's very likely that it's responsible for R/W access to CF card, right?

http://wiki.xda-developers.com/index.php?pagename=HimalayaGPIO
As you can see GPIO2 Backpack IRQ hooks into nk.exe, that is the Himalaya WM2003 any version official releases... There are several other known details about Backpack in these pages http://wiki.xda-developers.com/index.php?pagename=HimalayaHardware but the amount of information does not yet make me happy.

There has been a leaked out WM5 Hima beta that has never been officially released, but some, very rare, ppl on buzzdev reported having Backpack battery and/or CF working using that ROM...

cmonex

25th October 2007, 06:01 AM

if you want to understand the kernel disassembly, you must understand C too, because using the C sources for the kernel (the shared source in platform builder) will make it *lots* easier.

i don't think you can port the driver without rewriting it in C/C++, so that's another reason why that'd be a requirement.
unless the modification that is needed is simple in asm...

but even to find what the problem is, is not a trivial task at all.

BTW what is your guess about how nk.exe is related to the problem? i'm curious.

do you have this beta wm5 where this backpack thing works? that would make this task quite a lot easier.

Maggy

26th October 2007, 12:52 AM

if you want to understand the kernel disassembly, you must understand C too, because using the C sources for the kernel (the shared source in platform builder) will make it *lots* easier.

Are the kernel C sources public? Or is there a way to decompile them?? That would indeed make things easier.

BTW what is your guess about how nk.exe is related to the problem? i'm curious.

IMHO,MVVHO it seems clear to me from the GPIO table

do you have this beta wm5 where this backpack thing works? that would make this task quite a lot easier. It did not work for all, most tried and failed, some where lucky. Himalaya's can be nasty critters. I have here two "identical" Hima's, both type PH10B, both same ROM, same bootloader, same radio, same RAM configuration. I bought both with broken screen, bought 2 screens with identical part # from same seller, but one is much darker than the other. No problem, I use mine (the darker one) always at 40% backlight and it's still comfortable reading. But strange.
Even stranger, I tried to install the same bunch of software on both, even in the same order. Some programs that ran smootly on A crashed B vice versa...

I think HTC was still trying to find out how to separate the experimental department from the construction line in those days...

Back to your question, it was a very early unstable beta, I tried it, went back to WM2003, deleted that beta :-( I could not foresee that it could play such a crucial role later in history.
Shortly afterwards Microsoft started law suit threats against the founders of xda-dev and buzznet, all these early ROMs were taken off ftp sites. I PMmed some of the members who tried it, especially those who reported working Backpacks... no chance...

cmonex

27th October 2007, 12:08 AM

as i said: shared sources from platform builder. most of the kernel source is available in there. :) let me know if you can't find PB 5.0. i have the download links for the eval version and the eval license key.

decompiling, dream on..

could you please go into details on the GPIO? this would make matters much more clear.

i hope you can find that rom somehow. that would make this case less hopeless.

epimazzo

28th February 2009, 02:51 PM

Is it correct modify NK to extend its memory from 84 to 100mb as we are dealing with the Kernel?
I tried by altering the following hex address in S000 but it didn't work:(

From 9FE530559FE5A13EA0E38224A0E3
To 9FE530559FE5A13EA0E38324A0E3

I can't boot anymore. Always stuck on 2nd splash. But if I removed it, it boots fine but keeping 84mb program memory instead 102.

Any idea folks?

Thanks:cool:

nk.exe is the kernel, period. ;)