We are receiving the sc-win32-Status code as -2147023901 in case of Failed Requests. We didnt get much info when we googled on net.
Please throw some light as to whether the issue is related to any Network issue.
I would guess that error is really 995:
ERROR_OPERATION_ABORTED
The I/O operation has been aborted because of either a thread exit or an application request.
Some libraries combine normal Windows error codes with some flags in the upper 16 bits of a DWORD value, which can hide the original number. If I see a negative number error code around -2100000000, I do this:
Convert to hex (with calc.exe or whatever) In this case decimal -2147023901 is hex 0x800703E3.
Take the lower 16 bits (0x00003E3)
Try to look that up. For instance, on MSDN.
Another handy trick that often works is to see if it can be decoded by certutil -error. From a command line:
C:\>certutil -error -2147023901
0x800703e3 (WIN32: 995) -- 2147943395 (-2147023901)
Error message text: The I/O operation has been aborted because of either a thread exit or an application request.
CertUtil: -error command completed successfully.
Related
Suppose we have the following situation:
launch_kernel_a<<<n_blocks, n_threads>>>(...);
launch_kernel_b<<<n_blocks, n_threads>>>(...);
cudaDeviceSynchronize();
if(cudaGetLastError() != CudaSuccess)
{
// Handle error
...
}
My understanding is that in the above, execution errors occurring during the asynchronous execution of either kernel may be returned by cudaGetLastError(). In that case, how do I figure out which kernel caused the error to occur during runtime?
My understanding is that in the above, execution errors occurring during the asynchronous execution of either kernel may be returned by cudaGetLastError().
That is correct. The runtime API will return the last error which was encountered. It isn't possible to know from which call in a sequence of asynchronous API calls an error was generated.
In that case, how do I figure out which kernel caused the error to occur during runtime?
You can't. You would require some kind of additional API call between the two kernel launches to determine the error. The crudest would be a cudaDeviceSynchronize() call, although that would serialize the operations if they actually did overlap (although I see no stream usage so that is probably not happening here).
As noted in comments -- most kernel runtime errors will result in context destruction, so if you got an error from the first kernel, the second kernel will abort or refuse to run anyway and that is probably fatal to your whole application.
I'm try to publish my data to ThingsBoard server i use this types of AT commands
AT+QIACT=1
OK
AT+QMTOPEN=1,"demo.thingsboard.io",1883
OK
AT+QMTCONN=1,"demo.thingsboard.io","MY_ACCESS_TOKEN",""
OK
AT+QMTPUB=1,0,0,0,"v1/devices/me/telemetry"
>{"temperature":35.00,"humidity":80.00} // MY_POST_DATA This line hanging my module
All AT commands response is ok But i finally enter MY_POST_DATA the module doesn't provide no response hanging the previous command.. and i check my ThinksBoard data never post telemetry..
Please help any one how can i fix this problem and publish MQTT server.
Step 1: Get hold of the official AT command documentation for the modem (Quectel BG96 I assume?). It should document how the AT+QMTPUB command behaves and what it expects. Everything else is just guessing. The manufacturer should provide this, and if not you should demand to get one.
...
Step 873, when you have exhausted absolutely all possible ways of getting hold of the official AT command documentation for the modem: You can try my guess that the command behaves similar to other commands that read arbitrary length user data, most notably AT+CMGS which sends SMS messages, which expect a Ctrl-Z (ascii value 26) as an end of data indicator.
+QMTPUB: 1,0,0 simply mean that BG96 has successfully published and your broker (thingsboard) have also acknowledged publication of message.
If you can't see data on broker, then please check if the topic you are publishing is correct or not.
It may happen you are publishing to another topic (or to a different PATH).
Ask 'thingsboard' for help regarding proper topic.
I am trying to Enqueue a message onto an Oracle Queue from a .NET client. If the message exceeds a certain size, the following error occurs:
ORA-01013: user requested cancel of current operation
This happens with both XMLTYPE and raw as the queue table's message type.
It seems that the size of the message is to blame but cannot tell for sure be cause of the limited Oracle error message.
Is there a limit on the size, can I increase the size or is there another way to overcome this issue?
Update:
I am able to send the message directly with dbms_aq.enqueue(...)
Setting the timeout from the .NET client does not have any effect. (It times out immediately regardless of the timeout value)
This sounds like a connection timeout from the .net client. Try increasing the timeout. If that doesn't work, check if the issue is with the message payload by inserting the message directly through dbms_aq.enqueue(...). If you are able insert, then the message itself is fine.
There are a couple of size-related issues being fixed for 11.2.0.3. See this non-authoritative list here:
http://www.eygle.com/Notes/11.2.0.3.html
Some examples:
9878459 Specific length object binds over 4k may be bound as NULL
10389881 Raw buffered message payload > 8k corrupted when dequeued
from a buffered queue
Maybe, your issue is in this list?
I've got to invoke a RPC service, and all the parameters sent are String. It works quite well when the data is relatively small, but when one of the string grows to the size about 10 or over hundred KB, immediately after the service is invoked, it goes to the error handler:
[FaultEvent fault=[RPC Fault faultString="Error #2006: The supplied index is out of bounds." faultCode="InvokeFailed" faultDetail="null"] messageId="85CF2FB3-E79D-779F-87F9-B04520318D3A" type="fault" bubbles=false cancelable=true eventPhase=2]
And the server side still got invoked, and when it returns the result, error raised:
Error: Command already finished executing: [object AsyncTokenCommand]
Google says error #2006 may because of too many hierarchy levels, which seems impossible to me because all my parameters are string. And I also don't have the chance to mistake on index.
I first thought it was because the string sent is too long, I segmented it and sent in a list, but didn't work.
Thanks in advance if you guys can give any help.
Finally got it right.
It was because I turned on the Network Monitor in Flash Builder.
Everything OK after it's off.
when i write log to windows eventlog:
System.Diagnostics.EventLog.WriteEntry("SourceName", a_long_string);
i got the following exception:
Log entry string is too long. A string written to the event log cannot exceed 32766 characters.
then i splits my log message into 2 or more string. but i don't think it is a good idea.
any workarounds? (such as extern the limit per log entry)
The Event Log isn't intended for storing Chapter 1 of War and Peace. You really should reconsider what you're writing to the event log.
If you want to log something voluminous (e.g. a crash dump), you can always store it somewhere on disk and write a message to the EventLog something like Generated dump at C:\Users\MyUserName\AppData\Local\MyApp\WarAndPeace.pdf.