Problem with sql.dll and clan.dll

[Kakdela]

Hello maybe some has met this problem when we try start server it always crash , then we find problem , server has to low memory , we add it up to 2 GB, then again crash , and we add up to 3gb , and it work , but problem start with sql and clan.dll , when we login in game or create char it crash always .... with ODBC all work good

server configure

CPU : I7
Ram: 16 GB
HDD: 3 TB
Windows : 2008 64 bit standart edition
Sql server : 2012 .

 

[Vormav]

Check your BillingDBErrorYearMonthDay.log (eg. BillingDBError20120914.log) it will show you all SQL/Clan .dll errors and bad queries.
It look like bad data taken from MSSQL that PT can't process.

 

[Kakdela]

Check your BillingDBErrorYearMonthDay.log (eg. BillingDBError20120914.log) it will show you all SQL/Clan .dll errors and bad queries.
It look like bad data taken from MSSQL that PT can't process.

hello wormav , but we dont have any error logs with sql.dll ... really strange ...

 

[Vormav]

On 64bit OS server is reading registry configuration from:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PristonTale\GameServer

You need path to where logs are saved there:

"LogPath"="C:\\Logs"

 

[Kakdela]

On 64bit OS server is reading registry configuration from:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PristonTale\GameServer

You need path to where logs are saved there:

"LogPath"="C:\\Logs"

hello , thanks 1 problem we fix , now it not crash when you try login game. with exist char but it crash when you quit or create new char.

but clan.dll still crash

221101|SQLLogon===== ****'s sRet[1] lpszGPCode[PTP-RUD001] lpszDisuseDay [1355263200] lpszUsePeriod [0] lpszPCRNo [0] [32]

 

[Vormav]

Try different .dll's or hotuk.ini configuration. I have no other idea why your server crash when someone exit game.

 

[Kakdela]

Try different .dll's or hotuk.ini configuration. I have no other idea why your server crash when someone exit game.

maybe thats why we set 3GB memory for server and sql.dll and clan.dll is 32bit ?

but if we not set 3 GB memory server not start

 

[bobsobol]

I'm not sure what you mean about the memory thing. You quote many figures.

So, the hardware is 16Gig RAM? VC7 (Visual Studio 2003, which compiled the server) always sets a 2Gig "flat" memory model for compiled programs. The routines in it's standard libraries and frameworks are not guaranteed to work with more. You can modify the PE (the .exe file) to make the kernel allocate up to 4Gig of "flat" memory. But there is no guarantee that any particular routine, function or included library will know how to handle that much memory.

flat memory: Traditional 16-bit applications used "paged" memory, (even without a "page" or "swap" file or partition [that's something different... based on a similar principal, but different]) and would manage paging sections into and out of the 16-bit (64 Kilobytes) memory space for themselves. 32-bit applications still have the ability to do that, and thereby access more than the 4Gig of memory addressable in 32-bits. Windows doesn't support this within applications however, and reserves such instructions for kernel level (supervisor) code only.

Spoiler

Because neither Windows, nor Linux, nor Mac OS, BSD, BeOS or any other well conceived and "complete" OS ever made use of this ability, it has proven to be unreliable between CPU revisions and require many, many work-arounds to achieve, even on a completely new OS without any legacy software issues. The attempt to unify these into a single hardware API was called PAE. (

To view the content, you need to sign in or register

)

Now, it works, but is a huge pain in the backside, and when Windows attempts to utilise it (because of their "legacy software" restrictions) they can only do so to "claw back" the (almost) 1 gigabyte of that 4Gig the OS usually gives over to making other things run smoother. (Memory mapped files and IO, BIOS extensions and fixed addressing kernel modules)

The best implementations of PAE (and all of the ones on 64-bit capable processors) also include PAE-NX with enables hardware DEP in Windows. This system ensures that nasty things like the GFantasy (common in PT servers and many of the older clients) section addition are illegal at a hardware, CPU level. No memory block / section should be Writeable and Executable.

If you have done the "over 2Gig patch" on the server PE and your executable includes such a section (ewww) then you should break the additions in it down into code, constants and variables, and give each kind of addition a section of it's own, with the correct permissions.

Additionally, the routines in the executable do not expect to be able to allocate, or address more than 2Gig, and many "loops" may expect to "wrap around" memory pointers which are incremented above 0x80000000. (By which I mean that they expect that 0x80000000 + 1 = 0x00) This will no longer happen. (0x80000000 + 1 will now equal 0x80000001) That may greatly confuse them... or it may fix bugs in them if their developers (who probably couldn't find a machine with more than a Gig of RAM for the entire system back between 2000 and 2006) may not have been aware of this limitation to debug it. Many developers assumed that the user "hype" that a 32-bit CPU will address 4Gig was just simply "true" in all circumstances, and addresses would not wrap around until you reached 0xFFFFFFFF. (a logical assumption, until you understand how the IBM compatible hardware and Windows OS (and Linux) use it. XD (If MacOS had remained on the PPC series processors and it's EFI hardware, I believe the expected result would be true on their 32-bit CPUs. I knew of this, because I was keen on the BeOS, before it got taken off desktops and turned into the newer incarnations of PalmOS. They supported bot x86 and PPC and discussed the differences of the platforms from the OS perspective. ^_^)

There is no switch in the PE, or the WOW6432 "emulation layer" (virtual machine) which runs 32-bit applications on a 64-bit CPU and OS, to extend the memory specification from 3Gig to 4Gig. It is either 2Gig, or "all you can give me within the 32-bit address space". (ie. 4Gig if PAE is enabled, or as close to it as possible [varies according to hardware and BIOS etc] if it is not)

In 16/32-bit (DOS with EMM & XMS extenders and "protected mode" such as DOS4GW, CWDPMI etc) or Windows 9x, there where other models. "Compact", "Small", "Extended" or "Large" where popular terms. All basically related to the size of pages which could be moved into different address spaces. Even without extenders, the way we got 640K on a classic 8086 was via the base pointer registers DS, ES, BP & SS for Data, Extra, Base and Stack "frames". Their 32-bit equivalents can now be used almost as any general register. EDS and EBP certainly often are.

What exactly have you done to "increase the memory"? I am Very curious, and I suspect you may not have considered all the implications of your action. ^_^

 

[gzuz]

remove your dll's. Download the dll's from grego's website and set the connection within to your localip/sqlexpress.

Delete Char Data folder and ensure that all of your char/field data is not corrupted. if you are using MPT server. Do not import the char/field folder from MPT client, rpt files can easily corrupt.

 

[Kakdela]

we use own files . we have added alot , its old majestyPT files . not 4096 files ...
it crash at this

char *somedata;// points to some valid data at address 0xC0000000

char *p = somefunc(somedata); // returns 0
if ( (p - somedata) > 0 )
{
use_data(p);
}

no crash if we set to "0x7fffffff (2Гб)." , but then not start server

 

[bobsobol]

Yes. So either one of those routines doesn't support more than 2Gb (<= 0x80000000) or you have not allocated the memory correctly.

Such edits are often made without care for the change in memory mapping between OS, hardware and sometimes even core system patch levels. (service packs, DirectX versions, MDAC version, drivers and Chipset and Gfx drivers in particular etc.)
Because you are developing a program which is not only compiled to binary, but linked to the OS, and active in memory, people often address memory directly, rather than via APIs. The kernel will load memory blocks into different memory locations on different hardware or OS version and the code will no longer work.

For reference,

To view the content, you need to sign in or register

 

[Kakdela]

Yes. So either one of those routines doesn't support more than 2Gb (<= 0x80000000) or you have not allocated the memory correctly.

Such edits are often made without care for the change in memory mapping between OS, hardware and sometimes even core system patch levels. (service packs, DirectX versions, MDAC version, drivers and Chipset and Gfx drivers in particular etc.)
Because you are developing a program which is not only compiled to binary, but linked to the OS, and active in memory, people often address memory directly, rather than via APIs. The kernel will load memory blocks into different memory locations on different hardware or OS version and the code will no longer work.

For reference,

To view the content, you need to sign in or register

this generator not help , its show same problem , its problem with 32 bit , becouse dll is for 2gb not for more ....

 

[bobsobol]

Aha! Correct, and they are so complex nobody has been able to completely replace them. So there is no avoiding the 2Gig limit on the SQL DLLs. (actually, I suspect that what they do is not so complex, but the way they are coded and work is)

More importantly; it is those DLLs which are heavily dependent on the MSVCRT DLLs which are in many releases, and they will never support more than 2Gig. They are ridiculously complex for a basic C Runtime library. (probably the most convoluted version of Visual C++ ever) Reversing, or replacing them will be incredibly difficult.

 

[gzuz]

I dissagree firmly. I have been running PT on an 8gb(and briefly a 12gb until 4b went corrupt) system for a long time. If you have made modifications to the memory map however then that is where your problem lies.

 

[Kakdela]

our coder is re-writing it now for 64 bit , but i hope server.exe dont have same **** .... but sql.dll and clan.dll re-write will take 3-4 weeks

 

[Vormav]

You can't mix 64bit .dll and 32bit .exe, you can however set flag in .dll "app can handle >2GB address space"... MAYBE it will do some MAGIC in background

Post some ASM code from olly, I wonder what data is processed in that function.
Could you try running your server with clean SQL Database (no records) and without "char" and "Field" folders?

 

[bobsobol]

Yea... there's a lot of misunderstanding here.

Gzuz: I would say (in my terminology) that you cannot run PT server on more than 4Gig. Because even if the physical machine has more than 4Gig, the PT server cannot address or see that memory. You can have as much memory on the PC as you like. That won't affect PT, and I'm not suggesting it will. All I'm saying is that PT is a 32-bit application running in a "virtual" 32-bit address space which cannot exceed 4Gig, and there is unlikely to be more than 3Gig of that "free" in that address space when the image (the initial exe file) is loaded into it. That "virtual" address space isn't the entire memory space on a 64-bit OS, but it is all the memory that the PT server executable, and any DLLs imported into it will be able to see.

Vormav: You can enable the > 2Gig Flat memory flag for PT, and I know from my experience that that doesn't instantly have an adverse affect on the PT server. But that image (the server executable) doesn't use the MSVCRT DLLs. They don't have the flag set, and the Clan.dll and SQL.dll do rely on them quite heavily.

It was my understanding (from the MS documentation I have read) that if the process is created with > 2Gig flag, then somewhere between 3 and 4 Gig will be in the "virtual" flat memory space of the entire process. However, if you then set that flag on SQL.dll and / or Clan.dll...? I don't know what will happen. Setting it on either of those, and not setting it on the shared MSVC dlls sounds like a bad idea. Setting it on all of them could well be a disastrous idea, and not setting it on any of them may not give you the memory boost within the process that you hope for.

Beyond that, I cannot honestly say that I know what may happen. What I can say is that I would expect results to vary greatly between Windows NT, (by which I mean everything from NT3 to Windows 7) Windows 9x (any Windows OS running under DOS, and not the NT kernel) and Wine. I would also expect a fair amount of difference in the memory map between every version and SP revision of Windows.

I believe that this "bug" will get very complex and sticky very quickly.

 

[Kakdela]

Vormav , but problem is in sql.dll and not server.exe , .exe work good , we didnt find anythink bad , and we not writing it for 64 bit , but writing for more memory...

 

[bobsobol]

There is no more memory in 32-bit. tt1: This is why what you are saying makes little sense.

Additionally, SQL.dll doesn't create a process. It is simply injected into the process the Kernel creates for Server.exe, and it is the flag on that which is key.

The memory allocation performed by SQL.dll is actually managed by the MSVCRT DLLs which are (should be) shared and also do not have the > 2G memory flag.

You are looking purely at the DLL, and while you can do that with server.exe and see that it works okay but (maybe) doesn't really use the extra address space you have allowed it to, the scope of the issue for DLLs is much much larger. You must look carefully at all dependencies and interoperability. (ie. other programs may also be using the MSVCRT DLLs loaded in the same physical memory, but addressed at different locations within their virtual memory space / map)

You are talking about a change which affects an entire continent, and you are telling us about just a single football field. Like that's all that counts. ^_^

The case may be that that's all that counts to you, but there will probably be considerable come-back from the way this "simple change" affects everything else in your system.
(at least the virtual 32-bit system it is running in)

You say you aren't adapting it to 64-bit, but

server configure

CPU : I7
Ram: 16 GB

That isn't possible in 32-bit. It just isn't. It's like saying "I'm using a live fish out of water, and normally the fish lives for days like that, but when I force it to breath air it dies, and I don't understand why."

We are saying "The fish lives fine on the surface in a bucket of water, maybe... You want a bigger bucket, or are you trying to graft working lungs onto this fish and do away with the bucket?" You see where we are coming from? "No, I just want it to breath air without the lungs or bucket." is kinda what we are getting back from you.

 

[Kakdela]

this problem solved , waiting for next about this re-writed dll