We Keep Coding

C# Windows Service - Getting Random Windows Error Reporting logs even when service not installed

I'm currently working on a C# Windows Service.
I'm logging various things to the Windows Event Log, and using the Event Viewer to check the results.
As happens during development, things don't work, and every now and then Service would break and the Windows Error Reporting would log lots of entries like
Fault bucket , type 0
Event Name: CLR20r3
Response: Not available
Cab Id: 0
Problem signature:
P1: MyServiceName.exe
P2: 1.0.0.0
P3: 5b9fcf54
P4: MyServiceName
P5: 1.0.0.0
P6: 5b9fcf54
P7: 280
P8: 16e
P9: System.NullReferenceException
P10:
Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF8E3.tmp.WERInternalMetadata.xml
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_MyServiceName_...
Analysis symbol:
Rechecking for solution: 0
Report Id: 7c7efe65-6759-4a75-8581-72bc12182800
Report Status: 100
Hashed bucket:
Cab Guid: 0
All fair enough, or so I thought.
The problem is that I'm getting these reports at random times as well.
It might log them after five minutes, or half an hour, or anywhere in between.
I started off thinking something was broken, and trying to find the bug, but then it logged a load of errors while the service was uninstalled. Not just not running, completely uninstalled.
I have now tried all of the following, and I am STILL getting these random Windows Error Reporting logs, which is making it impossible to tell actual problems from this random junk:-
1) Uninstall the Service
It's not showing up in the Services App list.
If I start a Command Prompt in Administrator mode and type:
C:\WINDOWS\system32>sc queryex MyServiceName
it returns
[SC] EnumQueryServicesStatus:OpenService FAILED 1060:
The specified service does not exist as an installed service.
If I look through Processes and Services in Task Manager, nothing shows up
The service is uninstalled!
2) Rebooting
Just in case something was still in memory
3) Deleting every reference to MyServiceName in the Windows Registry
In case these was a dodgy registry key still kicking about
4) Rebooting
If all else fails...
5) Deleting the .EXE file
So there's no way it can be loaded and run
6) Rebooting yet again
Because why not!
And still, within a few minutes of rebooting, there they are...
Fault bucket , type 0
Event Name: CLR20r3
Response: Not available
Cab Id: 0
Problem signature:
P1: MyServiceName.exe
P2: 1.0.0.0
P3: 5b9fcf54
P4: MyServiceName
P5: 1.0.0.0
P6: 5b9fcf54
P7: 280
P8: 16e
P9: System.NullReferenceException
P10:
Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF8E3.tmp.WERInternalMetadata.xml
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_MyServiceName_...
Analysis symbol:
Rechecking for solution: 0
Report Id: 7c7efe65-6759-4a75-8581-72bc12182800
Report Status: 100
Hashed bucket:
Cab Guid: 0
And a couple of dozen others just like it.
I haven't installed or run the Service since I started trying to get rid of these random errors, and as I mentioned I've even deleted the .EXE files so it can't be installed or run.
Anyone know why I'm still getting this random junk, and more importantly how to stop it?
Edit: JuanR asked for the AppCrash file, so here it is:-
Version=1
EventType=CLR20r3
EventTime=131817392609639254
ReportType=2
Consent=1
UploadTime=131817585683279486
ReportStatus=100
ReportIdentifier=428e2b66-f3ae-461f-8221-df0633ba6dad
IntegratorReportIdentifier=e2ac36e7-3506-403f-9efc-cd22cfac94da
Wow64Host=34404
Wow64Guest=332
NsAppName=MyServiceName.exe
OriginalFilename=MyServiceName.exe
AppSessionGuid=000015b4-0000-0007-71e5-c234384fd401
TargetAppId=W:00064dae5f701edaa06ce44c0466d2ceb81300000000!0000a6504bbe6f18e0042ad1f80d12f5a7c97896d572!MyServiceName.exe
TargetAppVer=2018//09//18:10:11:10!0!MyServiceName.exe
BootId=4294967295
ServiceSplit=13
TargetAsId=2065
IsFatal=1
Response.type=4
Sig[0].Name=Problem Signature 01
Sig[0].Value=MyServiceName.exe
Sig[1].Name=Problem Signature 02
Sig[1].Value=1.0.0.0
Sig[2].Name=Problem Signature 03
Sig[2].Value=5ba0cf3e
Sig[3].Name=Problem Signature 04
Sig[3].Value=System
Sig[4].Name=Problem Signature 05
Sig[4].Value=4.7.3151.0
Sig[5].Name=Problem Signature 06
Sig[5].Value=5b44403a
Sig[6].Name=Problem Signature 07
Sig[6].Value=2da3
Sig[7].Name=Problem Signature 08
Sig[7].Value=11f
Sig[8].Name=Problem Signature 09
Sig[8].Value=System.Security.Security
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=10.0.17134.2.0.0.256.48
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=2057
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=2beb
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=2beba6fb4680d73a8c78ca7c24ccdb46
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=b1f0
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=b1f0b380dbcd74b72a4df4e63607c2ae
UI[2]=C:\TFSOnline\Tools\MyServiceName\MyServiceName\bin\Debug\MyServiceName.exe
UI[5]=Check online for a solution (recommended)
UI[6]=Check for a solution later (recommended)
UI[7]=Close
UI[8]=MyServiceName stopped working and was closed
UI[9]=A problem caused the application to stop working correctly. Windows will notify you if a solution is available.
UI[10]=&Close
LoadedModule[0]=C:\TFSOnline\Tools\MyServiceName\MyServiceName\bin\Debug\MyServiceName.exe
LoadedModule[1]=C:\WINDOWS\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\WINDOWS\SYSTEM32\MSCOREE.DLL
LoadedModule[3]=C:\WINDOWS\System32\KERNEL32.dll
LoadedModule[4]=C:\WINDOWS\System32\KERNELBASE.dll
LoadedModule[5]=C:\WINDOWS\System32\ADVAPI32.dll
LoadedModule[6]=C:\WINDOWS\System32\msvcrt.dll
LoadedModule[7]=C:\WINDOWS\System32\sechost.dll
LoadedModule[8]=C:\WINDOWS\System32\RPCRT4.dll
LoadedModule[9]=C:\WINDOWS\System32\SspiCli.dll
LoadedModule[10]=C:\WINDOWS\System32\CRYPTBASE.dll
LoadedModule[11]=C:\WINDOWS\System32\bcryptPrimitives.dll
LoadedModule[12]=C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscoreei.dll
LoadedModule[13]=C:\WINDOWS\System32\SHLWAPI.dll
LoadedModule[14]=C:\WINDOWS\System32\combase.dll
LoadedModule[15]=C:\WINDOWS\System32\ucrtbase.dll
LoadedModule[16]=C:\WINDOWS\System32\GDI32.dll
LoadedModule[17]=C:\WINDOWS\System32\gdi32full.dll
LoadedModule[18]=C:\WINDOWS\System32\msvcp_win.dll
LoadedModule[19]=C:\WINDOWS\System32\USER32.dll
LoadedModule[20]=C:\WINDOWS\System32\win32u.dll
LoadedModule[21]=C:\WINDOWS\System32\kernel.appcore.dll
LoadedModule[22]=C:\WINDOWS\SYSTEM32\VERSION.dll
LoadedModule[23]=C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
LoadedModule[24]=C:\WINDOWS\SYSTEM32\MSVCR120_CLR0400.dll
LoadedModule[25]=C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\mscorlib\399032397425364b053c532bbbeacc09\mscorlib.ni.dll
LoadedModule[26]=C:\WINDOWS\System32\ole32.dll
LoadedModule[27]=C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll
LoadedModule[28]=C:\WINDOWS\System32\OLEAUT32.dll
LoadedModule[29]=C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System\6e52f5ddc8a0027c55a2c15df97d50a9\System.ni.dll
LoadedModule[30]=C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System.Core\2d2bc5d43039ac23595b27676dcfcd3b\System.Core.ni.dll
LoadedModule[31]=C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System.Configuration\ce7b3ccf1b67903e135f62bd847db8dc\System.Configuration.ni.dll
LoadedModule[32]=C:\WINDOWS\System32\shell32.dll
LoadedModule[33]=C:\WINDOWS\System32\cfgmgr32.dll
LoadedModule[34]=C:\WINDOWS\System32\shcore.dll
LoadedModule[35]=C:\WINDOWS\System32\windows.storage.dll
LoadedModule[36]=C:\WINDOWS\System32\profapi.dll
LoadedModule[37]=C:\WINDOWS\System32\powrprof.dll
LoadedModule[38]=C:\WINDOWS\System32\FLTLIB.DLL
LoadedModule[39]=C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System.Xml\536177f34c4c0eeb95bcccd76ca90847\System.Xml.ni.dll
LoadedModule[40]=C:\WINDOWS\SYSTEM32\bcrypt.dll
LoadedModule[41]=C:\WINDOWS\SYSTEM32\CRYPTSP.dll
LoadedModule[42]=C:\WINDOWS\system32\rsaenh.dll
LoadedModule[43]=C:\WINDOWS\SYSTEM32\iphlpapi.dll
LoadedModule[44]=C:\WINDOWS\SYSTEM32\DNSAPI.dll
LoadedModule[45]=C:\WINDOWS\System32\WS2_32.dll
LoadedModule[46]=C:\WINDOWS\System32\NSI.dll
LoadedModule[47]=C:\WINDOWS\SYSTEM32\dhcpcsvc6.DLL
LoadedModule[48]=C:\WINDOWS\SYSTEM32\dhcpcsvc.DLL
LoadedModule[49]=C:\WINDOWS\SYSTEM32\WINNSI.DLL
LoadedModule[50]=C:\WINDOWS\SYSTEM32\activeds.dll
LoadedModule[51]=C:\WINDOWS\SYSTEM32\adsldpc.dll
LoadedModule[52]=C:\WINDOWS\System32\WLDAP32.dll
LoadedModule[53]=C:\WINDOWS\System32\clbcatq.dll
LoadedModule[54]=C:\WINDOWS\system32\adsldp.dll
LoadedModule[55]=C:\WINDOWS\SYSTEM32\sxs.dll
LoadedModule[56]=C:\WINDOWS\SYSTEM32\wkscli.dll
LoadedModule[57]=C:\WINDOWS\SYSTEM32\cscapi.dll
LoadedModule[58]=C:\WINDOWS\SYSTEM32\netutils.dll
LoadedModule[59]=C:\WINDOWS\SYSTEM32\logoncli.dll
LoadedModule[60]=C:\WINDOWS\system32\mswsock.dll
LoadedModule[61]=C:\Windows\System32\rasadhlp.dll
LoadedModule[62]=C:\WINDOWS\System32\fwpuclnt.dll
LoadedModule[63]=C:\WINDOWS\SYSTEM32\DSPARSE.dll
LoadedModule[64]=C:\WINDOWS\System32\msv1_0.DLL
LoadedModule[65]=C:\WINDOWS\SYSTEM32\NtlmShared.dll
LoadedModule[66]=C:\WINDOWS\SYSTEM32\cryptdll.dll
LoadedModule[67]=C:\Windows\Microsoft.NET\Framework\v4.0.30319\diasymreader.dll
LoadedModule[68]=C:\WINDOWS\System32\psapi.dll
LoadedModule[69]=C:\WINDOWS\SYSTEM32\rasapi32.dll
LoadedModule[70]=C:\WINDOWS\SYSTEM32\rasman.dll
LoadedModule[71]=C:\WINDOWS\SYSTEM32\rtutils.dll
LoadedModule[72]=C:\WINDOWS\SYSTEM32\winhttp.dll
LoadedModule[73]=C:\WINDOWS\SYSTEM32\secur32.dll
LoadedModule[74]=C:\WINDOWS\System32\schannel.dll
LoadedModule[75]=C:\WINDOWS\System32\CRYPT32.dll
LoadedModule[76]=C:\WINDOWS\System32\MSASN1.dll
LoadedModule[77]=C:\WINDOWS\SYSTEM32\mskeyprotect.dll
LoadedModule[78]=C:\WINDOWS\SYSTEM32\ncrypt.dll
LoadedModule[79]=C:\WINDOWS\SYSTEM32\NTASN1.dll
LoadedModule[80]=C:\WINDOWS\system32\ncryptsslp.dll
LoadedModule[81]=C:\WINDOWS\Microsoft.Net\assembly\GAC_32\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll
LoadedModule[82]=C:\WINDOWS\Microsoft.Net\assembly\GAC_32\System.Transactions\v4.0_4.0.0.0__b77a5c561934e089\System.Transactions.dll
LoadedModule[83]=C:\WINDOWS\Microsoft.Net\assembly\GAC_32\System.Data.OracleClient\v4.0_4.0.0.0__b77a5c561934e089\System.Data.OracleClient.dll
LoadedModule[84]=C:\WINDOWS\SYSTEM32\urlmon.dll
LoadedModule[85]=C:\WINDOWS\SYSTEM32\iertutil.dll
LoadedModule[86]=C:\WINDOWS\SYSTEM32\PROPSYS.dll
LoadedModule[87]=C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System.Xml.Linq\6e4d9ba028653154945437d7674d20a3\System.Xml.Linq.ni.dll
LoadedModule[88]=C:\WINDOWS\Microsoft.Net\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.Wrapper.dll
LoadedModule[89]=C:\WINDOWS\system32\security.dll
LoadedModule[90]=C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System.Runteb92aa12#\5470ed48a2649b4c1fd9e883daa502b9\System.Runtime.Serialization.ni.dll
OsInfo[0].Key=vermaj
OsInfo[0].Value=10
OsInfo[1].Key=vermin
OsInfo[1].Value=0
OsInfo[2].Key=verbld
OsInfo[2].Value=17134
OsInfo[3].Key=ubr
OsInfo[3].Value=286
OsInfo[4].Key=versp
OsInfo[4].Value=0
OsInfo[5].Key=arch
OsInfo[5].Value=9
OsInfo[6].Key=lcid
OsInfo[6].Value=2057
OsInfo[7].Key=geoid
OsInfo[7].Value=242
OsInfo[8].Key=sku
OsInfo[8].Value=48
OsInfo[9].Key=domain
OsInfo[9].Value=1
OsInfo[10].Key=prodsuite
OsInfo[10].Value=256
OsInfo[11].Key=ntprodtype
OsInfo[11].Value=1
OsInfo[12].Key=platid
OsInfo[12].Value=10
OsInfo[13].Key=sr
OsInfo[13].Value=0
OsInfo[14].Key=tmsi
OsInfo[14].Value=48160
OsInfo[15].Key=osinsty
OsInfo[15].Value=3
OsInfo[16].Key=iever
OsInfo[16].Value=11.285.17134.0-11.0.85
OsInfo[17].Key=portos
OsInfo[17].Value=0
OsInfo[18].Key=ram
OsInfo[18].Value=8144
OsInfo[19].Key=svolsz
OsInfo[19].Value=445
OsInfo[20].Key=wimbt
OsInfo[20].Value=0
OsInfo[21].Key=blddt
OsInfo[21].Value=180410
OsInfo[22].Key=bldtm
OsInfo[22].Value=1804
OsInfo[23].Key=bldbrch
OsInfo[23].Value=rs4_release
OsInfo[24].Key=bldchk
OsInfo[24].Value=0
OsInfo[25].Key=wpvermaj
OsInfo[25].Value=0
OsInfo[26].Key=wpvermin
OsInfo[26].Value=0
OsInfo[27].Key=wpbuildmaj
OsInfo[27].Value=0
OsInfo[28].Key=wpbuildmin
OsInfo[28].Value=0
OsInfo[29].Key=osver
OsInfo[29].Value=10.0.17134.286.amd64fre.rs4_release.180410-1804
OsInfo[30].Key=buildflightid
OsInfo[30].Value=39b802d6-2dc5-4161-973b-28cf09eb3ffb
OsInfo[31].Key=edition
OsInfo[31].Value=Professional
OsInfo[32].Key=ring
OsInfo[33].Key=expid
OsInfo[34].Key=containerid
OsInfo[35].Key=containertype
OsInfo[36].Key=edu
OsInfo[36].Value=0
File[0].CabName=WERInternalMetadata.xml
File[0].Path=WERCF72.tmp.WERInternalMetadata.xml
File[0].Flags=327682
File[0].Type=5
File[0].Original.Path=\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERCF72.tmp.WERInternalMetadata.xml
FriendlyEventName=Stopped working
ConsentKey=CLR20r3
AppName=MyServiceName
AppPath=C:\TFSOnline\Tools\MyServiceName\MyServiceName\bin\Debug\MyServiceName.exe
NsPartner=windows
NsGroup=windows8
ApplicationIdentity=9EE7A7FA2D9AD07D426D34AC6F6F0ACA
MetadataHash=1785215478
The path is mentions throughout is
C:\TFSOnline\Tools\MyServiceName\MyServiceName\bin\Debug\MyServiceName.exe
This is one of the EXEs I deleted. I also deleted the one in obj/Debug.
I've scanned the entire drive, using several methods, and no other instances of MyServiceName.exe exist, so it's not been copied anywhere.
And the one thing I realised I never mentioned: it's a Windows 10 machine
Edit #2:
None of the things the Service does, for example adding Windows Event logs, adding database table rows or creating files, are happening at the moment, so I'm reasonably sure the service isn't running.
I had all that working before starting to look into this issue, and haven't changed any of it since, so if it was running I'd expect to still see them.
To check, I've just re-installed the service as it was before, and I'm getting all the entries I expect.
Edit #3:
Tried deleting it with the SC command:-
C:\WINDOWS\system32>sc delete MyServiceName.exe
[SC] OpenService FAILED 1060:
The specified service does not exist as an installed service.

Solved it!
Nothing to do with the Service at all, just Windows being crap as always.
Turns out that every time Windows was logging a message, it was also churning out a load of old messages that had got stuck in its queue, and logging them as new messages.
I ran Disk Cleanup, and told it to clear out all the old error messages, and it's been running for three days now with no errors at all.

c# SerialPort: how to send "0 byte" transfers (AKA ZLP: zero length packet)?

I've done some playing around with SerialPort (frustratingly so) and have finally hit a point where I absolutely have no idea why this isn't working. There's a USB CDC device that I'm trying to send hex commands to, the way I'm doing this is over the COM port interface it exposes. I can handshake with the device, when I say HI it replies with HI back, but then I send another command to it which must be followed by a zero byte packet or else the device stops responding altogether. Keep in mind, this zero byte packet has ABSOLUTELY nothing in it, meaning it doesn't have a \0 or a 0x00 or 0 or even a null (SerialPort throws an exception on null).
Now, one way I was able to circumvent this was to use libusbdotnet. I accessed the CDC device directly instead of the COM interface, set the endpoints correctly and sent hex commands like that. I'm able to successfully send "0 byte" packets using this method with the following c# code:
string zlpstring = "";
byte[] zlpbyte = Encoding.Default.GetBytes(zlpstring);
....snip
ecWrite = writer.SubmitAsyncTransfer(zlpbyte, 0, zlpbyte.Length, 100, out usbWriteTransfer);
zlpbyte is the buffer, 0 is the offset, zlpbyte.Length is the packet length in bytes, 100 is the timeout, and out usbWriteTransfer is the transfer context.
When I use this same method on the COM port:
string zlpstring = "";
byte[] zlpbyte = Encoding.Default.GetBytes(zlpstring);
_serialPort.Write(zlpbyte, 0, zlpbyte.Length);
the USB logger reports that absolutely nothing was sent. It's as if the COM port is ignoring the zero byte transfer. Before it's mentioned that "you cannot do this", there's various programs out there that can send a zero-byte packet to this exact device's COM port without doing ANY driver manipulation. This is what I'm going for, which is why I'm trying to ditch libusbdotnet and go straight to the COM port.
EDIT:
After some more toying around and a different USB logger I don't find zero bytes being sent but rather this:
IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK)
I think this may be the issue. If a 0 byte was being sent then I assume it would show up as:
IRP_MJ_WRITE > UP > STATUS_SUCCESS > (blank) > (blank)
My program is sending back a response of 01 00 00 00, however while logging another successful program it's SETTING the wait mask:
IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_WAIT_MASK) DOWN STATUS_SUCCESS 01 00 00 00
If my assumptions are right, this question might've just turned into how do I set a serial port's/COM port's wait mask? There's absolutely nothing about this in the c# SerialPort class...which is why I can now see why so many articles called it "lacking". I also took a look around c++: https://msdn.microsoft.com/en-us/library/aa363214(v=vs.85).aspx this also does not seem to cover the wait mask. Using the USB filter libusb is starting to look a lot more pleasing each minute...(although I'm going to question myself forever why sending a zero byte works there but it doesn't over SerialPort).
SECOND EDIT:
I'm a moron. It was definitely a setting that the manufacturer probably didn't figure anyone would ever touch nor know how to set:
#define EV_RXFLAG 0x0001
SetCommMask(hSerial, EV_RXFLAG);
I then saw this over the USB logs:
IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_WAIT_MASK) DOWN STATUS_SUCCESS 01 00 00 00
Bingo. The RXFLAG was originally set to 0x0002. I couldn't find a way to change this in C# yet. So I had to do with some C++ code for now. It totally works, and sends the "zero byte" like it's supposed to without me actually sending it from the code. This setting I assume was the "handshake" method between my device and whatever else it's interacting with in Flash mode. Hope this helps someone else out there whose COM/Serial device is rejecting/discarding zero byte packets yet requiring ZLP at the same time...how goofy?!

have you tried to concatenate an extra new line or carriage return or both at the end of the data?
I would say add a 0xA (new line), or 0xD (carriage return), or both 0xA and 0xD to the end of your byte array and see if you get something.
byte[] zlpbyte = new byte[1] {0};
_serialPort.Write(zlpbyte, 0, 1);
[Update]
Based on our discussions, it appears that you are trying to have control over the control signals of the serial port. I have not tried it before but I can see that it is possible to set the control signals (if i understand the source properly) into certain states.
Try to set the Handshake property
public enum Handshake
{
None,
XOnXOff,
RequestToSend,
RequestToSendXOnXOff,
}
I am not sure exactly how it affects the IOCTL settings but it should be able to affect it somehow I believe

QuickFix Market Data Message Error

I am new to fix. I am using quick fix library in my app. Im able to do logon and exchange heart beat. When i send the marketdata request, im getting the response from the server. But my application is sending reject message to fix, when it receives a message. And so im not able to process the message. Below are the incoming and outgoing message.
20160623-11:19:45.898 : 8=FIX.4.49=24235=X34=12049=CfhDemoPrices52=20160623-11:19:46.41456=PrimoDEMOFIX262=PrimoApp123268=2279=1269=0278=30/23-14404955=GBPUSD270=1.48854271=1500000290=164=20160627279=1269=1278=30/23-14405455=GBPUSD270=1.48885271=1000000290=110=004
20160623-11:19:45.924 : 8=FIX.4.49=13735=334=12249=PrimoDEMOFIX52=20160623-11:19:45.92256=CfhDemoPrices45=12058=Tag not defined for this message type371=55372=X373=210=140
and below is how i subscribe for market data:
QuickFix.FIX44.MarketDataRequest msg = new QuickFix.FIX44.MarketDataRequest();
// Fill message fields
msg.SetField(new MDReqID("PrimoApp123"));
msg.SetField(new SubscriptionRequestType('1'));
msg.SetField(new MarketDepth(1));
msg.SetField(new MDUpdateType(1));
// Add the MDEntryTypes group
QuickFix.FIX44.MarketDataRequest.NoMDEntryTypesGroup noMDEntryTypes = new QuickFix.FIX44.MarketDataRequest.NoMDEntryTypesGroup();
noMDEntryTypes.SetField(new MDEntryType('0'));
msg.AddGroup(noMDEntryTypes);
// Add the NoRelatedSym group
QuickFix.FIX44.MarketDataRequest.NoRelatedSymGroup noRelatedSym = new QuickFix.FIX44.MarketDataRequest.NoRelatedSymGroup();
noRelatedSym.SetField(new Symbol("GBPUSD"));
msg.AddGroup(noRelatedSym);
// Send message
Session.SendToTarget(msg, FeederApp.mysession);
Please help me with this if possible

Did you even look at what your reject message says?
45=120 // RefSeqNum - seq num of message that was rejected
58=Tag not defined for this message type
371=55 // RefTagID - tag 55 is the problem
372=X // RefMsgType - the rejected message was an X (MarketDataIncrementalRefresh)
373=2 // SessionRejectReason 2=[TagNotDefinedForThisMessageType]
So according to this, the problem is that your DataDictionary is not configured to expect tag 55 (Symbol) inside of message type X.
However, that doesn't appear to be entirely accurate. If you're pasted message is correct, it breaks down like this:
8 =FIX.4.4
9 =242
35 =X
34 =120
49 =CfhDemoPrices
52 =20160623-11:19:46.414
56 =PrimoDEMOFIX
262 =PrimoApp123
268 =2 // 2 MDEntry Sequences
279 =1 // 1st sequence
269 =0
278 =30/23-144049
55 =GBPUSD // this looks ok here...
270 =1.48854
271 =1500000
290 =1
64 =20160627 // what? this doesn't belong here!
279 =1 // 2nd sequence
269 =1
278 =30/23-144054
55 =GBPUSD
270 =1.48885
271 =1000000
290 =1
10=004
Therefore, I suspect that either (1) you made an error when you copy/pasted your message, or (2) it's actually field 64 that is your problem.
Next Steps:
1) Read this page to learn how to customize the DataDictionary:
http://quickfixn.org/tutorial/custom-fields-groups-and-messages.html
2) Get documentation from your counterparty and make sure your DataDictionary reflects all the field/message customizations that they have added to their system.

Sphinx + xmlpipes2 + Mysql Connector. Problems with cyrillic

I have a problem configuring sphinx+mysql on my machine (Windows 7).
I use sphinx 2.0.6 and MySQL connector 6.5.5 to get to sphinx from C# code. Everything works fine when I try to search a words in English ("madrid" for ex.). But when I send a query from C# code which contains a cyrillic word (that had to be indexed) I receive no results. Here is what I see in the "query.log" file:
[Tue Mar 26 16:35:12.642 2013] 0.000 sec [ext2/0/ext 0 (0,10)] [airportIndex] ????
Latin words looks normal:
[Tue Mar 26 16:35:06.195 2013] 0.000 sec [ext2/0/ext 0 (0,10)] [airportIndex] *mosc*
The charset_table seems to be correct in config:
charset_type = utf-8
charset_table = 0..9, A..Z->a..z, _, a..z, \
U+410..U+42F->U+430..U+44F, U+430..U+44F, U+0401->U+0435, U+0451->U+0435
I just don't know what to do. I've googled for solution the whole day I tried many different solutions, but none of them helped me. Maybe anyone could help me here? Please...

Found it. It was a connector bug (or feature, I'm not sure). It was trying to get the server datetime offset, and failed because sphinx does not have this function. I've just commented this code line (inside MySql.Data.dll) and it started working correctly.

Retrieving product information from an unmanaged executing application in C#/.NET

In C#, it is possible to retrieve assembly related information like product name, version etc using reflection:
string productName = Assembly.GetCallingAssembly().GetName().Name;
string versionString = Assembly.GetCallingAssembly().GetName().Version.ToString();
How do I do the equivalent if the executing assembly is written in unmanaged C++ (say)? Is it even possible? Assume that I have a .NET dll which is being invoked in unmanaged code via a COM interface.
edit:
To make things absolutely clear, this is my scenario:
I have an executable written in
unmanaged C++
I have a dll written
in C#/.NET
The dll is invoked by the
executable via a COM interface
Within the .NET dll I want to be
able to retrieve information like
the product name and version of the
calling executable.
Possible?

Walking the stack is not necessary to find out what process you are in. You simply make a single Win32 API call:
HMODULE hEXE = GetModuleHandle(NULL);
According to the documentation for this call:
If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process (.exe file).
You can turn this module handle into a filename with GetModuleFileName(), another standard Win32 API. File name in hand, you can then call GetFileVersionInfo() to retrieve the VS_VERSIONINFO structure for that file. The information you want is in there.
Now since you are in .NET you could use P/Invoke signatures for GetModuleHandle(), GetModuleFileName(). For GetFileVersionInfo() you can use System.Diagnostics.FileVersionInfo.
But actually the easiest way to do it is probably to stick with the System.Diagnostics namespace, everything you need is there. Call System.Diagnostics.Process.GetCurrentProcess() to return a Process object for the process you are running in. Then you can retrieve a ProcessModule from the MainModule property. ProcessModule has a property called FileVersionInfo. The information you want is there.

you could use the following code in VB.Net to retrieve extended document properties:
Sub Main()
Dim arrHeaders(41)
Dim shell As New Shell32.Shell
Dim objFolder As Shell32.Folder
objFolder = shell.NameSpace("C:\tmp\")
For i = 0 To 40
arrHeaders(i) = objFolder.GetDetailsOf(objFolder.Items, i)
Next
For Each strFileName In objfolder.Items
For i = 0 To 40
Console.WriteLine(i & vbTab & arrHeaders(i) & ": " & objFolder.GetDetailsOf(strFileName, i))
Next
Next
End Sub
Add a COM reference to Microsoft Shell Controls and Automation to your project to compile.
The output of the above program will be a list of the meta data assigned to all files in C:\tmp such as
0 Name: dpvoice.dll
1 Size: 208 KB
2 Type: Application Extension
3 Date Modified: 14.04.2008 04:41
4 Date Created: 14.04.2008 04:41
5 Date Accessed: 01.12.2008 09:56
6 Attributes: A
7 Status: Online
8 Owner: Administrators
9 Author:
10 Title:
11 Subject:
12 Category:
13 Pages:
14 Comments:
15 Copyright:
16 Artist:
17 Album Title:
18 Year:
19 Track Number:
20 Genre:
21 Duration:
22 Bit Rate:
23 Protected:
24 Camera Model:
25 Date Picture Taken:
26 Dimensions:
27 :
28 :
29 Episode Name:
30 Program Description:
31 :
32 Audio sample size:
33 Audio sample rate:
34 Channels:
35 Company: Microsoft Corporation
36 Description: Microsoft DirectPlay Voice
37 File Version: 5.3.2600.5512
38 Product Name: Microsoftr Windowsr Operating System
39 Product Version: 5.03.2600.5512
40 Keywords:

Let's assume you're after an EXE/DLL's PE header data that #divo's calls return e.g. Company, Product etc... These btw. are derived from calling Win32 Version Info API's - details up on MSDN:
http://msdn.microsoft.com/en-us/library/ms646981.aspx
The next challenge you face is enumerating the callstack to discover your caller's module context. I've not tried - but if you examine your own callstack, I doubt you'll see the unmanaged caller's frames marshalled into there. Suspect it stops at transitional frame injected before switching into the CCW. Also since it's COM, conceivably the caller could call from out of process - your caller would be a proxy process.
If that fails - you'd need the debugging API's to unwind the external stack - that introduces other constraints:
elevated security permissions required to traverse the stack
potential performance impact unwinding the stack.
On a call-by-call basis either of these could make the debugger approach impractical.
Update
Some research indicates there are plenty of bugs and gotchas for reading the stack above the CCW transitional frame even in the debugger. e.g.
http://support.microsoft.com/kb/317221
Mixed Unmanaged/Managed symbol resolution is pretty ugly - some thoughts here on how to do it... DaveBr's blog on debugging is pretty awesome too.
http://bytes.com/groups/net-vc/280340-stackwalk-callstack-symbol-resolve-managed-unmanaged-code-dbghelp-etc
http://blogs.msdn.com/davbr/archive/2005/10/06/478006.aspx
There is plenty of fodder on the steps taken marshalling calls between unmanaged/managed clients - e.g.
http://msdn.microsoft.com/en-us/library/ms973872.aspx