access violation error in 'browse database' part of gui

Error and log included on the screenshot.

It happens as soon as I click 'browse database' tab in the gui. It crashes the conquest service too.
Except for that everything works just fine.

It's the newest one - 1419a, however this happens in earlier versions too (not sure how far back)

# This file contains configuration information for the DICOM server
# Do not edit unless you know what you are doing


[sscscp]
MicroPACS                = sscscp


# Network configuration: server name and TCP/IP port#
MyACRNema                = DICOMARCH
TCPPort                  = 5566


# Host, database, username and password for database
SQLHost                  = 127.0.0.1:5432
SQLServer                = conquest
Username                 = conquest
Password                 = tomo2005
Postgres                 = 1
DoubleBackSlashToDB      = 1
UseEscapeStringConstants = 1


# Configure server
ImportExportDragAndDrop  = 1
KeepAlive                = 60
ZipTime                  = 05:
UIDPrefix                = 1.2.826.0.1.3680043.2.135.736520.62657947
EnableComputedFields     = 1


FileNameSyntax           = %studydate[0,5]\%studydate[6,7]\%id\%modality_%studyuid\%seriesid_%sopuid.dcm


# Configuration of compression for incoming images and archival
DroppedFileCompression   = j2
IncomingCompression      = j2
ArchiveCompression       = j2


# For debug information
PACSName                 = DICOMARCH
OperatorConsole          = 127.0.0.1
DebugLevel               = 0


# Configuration of disk(s) to store images
MAGDeviceFullThreshHold  = 30
MAGDevices               = 1
MAGDevice0               = \\ARCHIWUM\pacs_archive\arch_studies\

edit:

it looks like it has sth to do with the owner of the service. It seems to be OK when launched as 'local system', but when launched as a specific user ( 'dicom_arch' in my case) I get the error.
Not rly sure why.. it clearly has access to PG because it works just fine.. it's just the browser.. somehow it's different.

edit2:

Test shows that everything is fine as long as the GUI is launched as the same user as the service. In my case if the service is launched with 'log on as dicom_arch' option then the gui (conquestdicomserver.exe) must be launched also as 'dicom_arch' user. Launching the .exe as admin doesn't help.

So I guess the mystery is solved. To be honest I'm not sure why it works that way.. but at least I know how to mitigate it.

That's the strange part - everything works except for this one tab.
I can clean database and re-initialize it just fine so it doesn't look like a connection/permission issue.
All test run fine.

Something must be different about this one tab.. only this one.

I spent last few hours trying to understand what is going on. Here is what I learned so far (which is not much I'm afraid)

First - few key points worth noting:
1) the Mag0 is a shared folder \\ARCHIWUM\
2) there are 2 windows user accounts used USER_A and USER_B.
USER_A is a standard user and is used to run dgate service (just to avoid running it with admin-level privileges)
USER_B is an admin user which I normally use.
Both users have access to mag0

I tested 3 cases:
a) USER_A runs the service. USER_A launches the GUI
b) USER_B runs the service. USER_B launches the GUI
c) USER_A runs the service. USER_B launches the GUI

In case a) and b) everything works fine.
In case c) GUI crashes (service also stops).

I can see the credentials used to access mag0 (smb log) and they are fine.

Running out of ideas...

Well.. yes. They both use the same credentials from the same .ini file.
also test b) wouldn't work then

Just to be clear - it happens only when the service is already running and then I try to run gui with different user... as in:

dgate service is already running (launched as USER_A) and then USER_B opens the GUI => error while clicking on 'browse db' tab
BUT
dgate service NOT running then USER_B opens the GUI => no error

sooo.. to sum it up, all possible cases:

only GUI (launched as USER_A) = no error
only GUI (launched as USER_B) = no error

service and GUI (both launched by USER_A) = no error
service and GUI (both launched by USER_B) = no error

service (by USER_A) and GUI (by USER_B) = error
service (by USER_B) and GUI (by USER_A) = error

It definitely looks like service is putting a lock on some crucial resource (file? port? no idea) which is tied directly to a user who launched it